Npgsql default parameter behaviour - npgsql

Question

If I have an update statement such as update foo set bar = #bar, baz = #baz, and create a command which is missing the parameters, it appears that the update will use the current values for those columns.
I haven't been able to find the documentation for this in either Npgsql or Postgresql - is it a supported feature than I can rely on, or just something that happens?
Trivial example:
using System;
using Npgsql;
namespace MissingParametersUpdate
{
static class Program
{
// you will need to have CREATE TABLE foo ( bar integer, baz integer )
static void Main(string[] args)
{
using (var connection = new NpgsqlConnection(args[0]))
{
connection.Open();
using (var command = connection.CreateCommand())
{
command.CommandText = #"delete from foo";
command.ExecuteNonQuery();
}
using (var command = connection.CreateCommand())
{
command.CommandText = #"insert into foo ( bar, baz ) values ( 1, 2 ), (3, 4)";
command.ExecuteNonQuery();
}
DumpValues("Initial", connection);
// empty update
using (var command = connection.CreateCommand())
{
command.CommandText = #"update foo set bar = #bar, baz = #baz";
command.ExecuteNonQuery();
}
DumpValues("Empty Update", connection);
// update bar
using (var command = connection.CreateCommand())
{
command.CommandText = #"update foo set bar = #bar, baz = #baz";
command.Parameters.AddWithValue(#"bar", 42);
command.ExecuteNonQuery();
}
DumpValues("Update Bar", connection);
// update baz
using (var command = connection.CreateCommand())
{
command.CommandText = #"update foo set bar = #bar, baz = #baz";
command.Parameters.AddWithValue(#"baz", 12);
command.ExecuteNonQuery();
}
DumpValues("Update Baz", connection);
}
}
private static void DumpValues(string caption, NpgsqlConnection connection)
{
Console.WriteLine(caption);
using (var command = connection.CreateCommand())
{
command.CommandText = #"select bar, baz from foo";
using (var reader = command.ExecuteReader())
while (reader.Read())
Console.WriteLine(" (bar: {0}, baz: {1})", reader.GetInt32(0), reader.GetInt32(1));
}
Console.WriteLine();
}
}
}

Answer 1

This is indeed a bit odd, here's what's going on.
PostgreSQL accepts positional parameter placeholders in the format $1, $2, etc. However, it is somewhat standard in .NET to have named placeholders, e.g. #bar, #baz. In order to support this, Npgsql parses your SQL client-side to find any parameter placeholders (e.g. #bar). When one is found, it looks for an NpgsqlParameter with the corresponding name on the NpgsqlCommand, and replaces it with a PostgreSQL-compatible positional placeholder (e.g. $1).
Now, if Npgsql encounters a placeholder without a corresponding NpgsqlParameter, it simply leaves it alone. At some point it threw an exception, but there were some cases in which Npgsql's internal SQL parser wasn't good enough and wrongly identified portions of the query as parameter placeholders. Leaving identified placeholders which don't have a corresponding NpgsqlParameter resolves this issue.
All that's for saying that your PostgreSQL receives the literal SQL update foo set bar = #bar, baz = #baz, without any sort of manipulation on Npgsql's part. Now, PostgreSQL consider # as a special character - you can define it as an operator (see https://www.postgresql.org/docs/current/static/sql-syntax-lexical.html). However, by default # doesn't appear to do anything at all, so what you actually did was run update foo set bar = bar, baz = baz, which obviously does nothing at all. You can see the # behavior by executing SELECT #foo - PostgreSQL will respond with an error saying column "foo" does not exist.
So it's an interplay between Npgsql leaving the query as-is because the parameter isn't set, and PostgreSQL ignoring the #.