Hello list,
I have been playing with the URI connection strings in the bleeding
edge 9.2 and noticed an inconsistency with the old connection string
behavior:
$ psql 'host=/var/run/postgresql dbname=postgres arbitrary=property'
psql: invalid connection option "arbitrary"
(psql exits with an error code immediately)
vs.
$ psql postgres://%2Fvar%2Frun%2Fpostgresql/?arbitrary=property
WARNING: ignoring unrecognized URI query parameter: arbitrary
(subsequent successful connection)
Both of these appear to be checked entirely client-side in libpq.
I view both of these approaches as problematic, because what I really
want for a more ambitious set of projects is to pass arbitrary
properties in the startup packet from libpq, as so that FEBE proxies
and potentially Postgres backend hooks/extensions can have a chance to
process the extra startup properties.
The clear downside of deferring some error messages until
post-connection is that typos would be harder to catch, so it seems
that warning should be retained for un-processed properties, but
instead be issued by the server. That might also make
forward-compatibility of libpq more complete, although I know that is
not an express goal (consider cases like when application_name was
added as a valid connection parameter, though).
This could also be useful for Postgres extensions.
Please send objections on the basis of principle.
If objections on the basis of principle are not heard or are
addressable, I'll follow-up with a summary of places where we might
need changes and ask for objections on mechanism next.
--
fdr