Daniel Farina <dan...@heroku.com> writes:
> 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"
> vs.
> $ psql postgres://%2Fvar%2Frun%2Fpostgresql/?arbitrary=property
> WARNING: ignoring unrecognized URI query parameter: arbitrary
Um. We oughta fix that. I'm not necessarily wedded to the old
throw-an-error definition, but there seems no good reason for these
two syntaxes to act inconsistently.
> 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 connection string does not really seem like the right place for that.
> The clear downside of deferring some error messages until
> post-connection is that typos would be harder to catch,
Or, indeed, impossible to catch. What if the typo causes libpq to fail
to contact the server at all? Good luck getting any assistance from
libpq in spotting your typo, if that happens and we've adopted this
sort of approach.
We already have a mechanism (PGOPTIONS, aka options=foo) for passing
through settings that will not be interpreted by libpq. I think that
stuff that is meant to be handled at the server end should be confined
to that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
