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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
