Re: Inconsistency in libpq connection parameters, and extension thereof

On Tue, Jun 5, 2012 at 6:43 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Daniel Farina <daniel(at)heroku(dot)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 agree with that. The URIs may have been done this way as a
concession to some small fragmentation that may have taken place
before URIs were standardized, but perhaps the author can speak to
that (he has been put on the To: list for this mail).

>> 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.

Interesting. Okay, I did not know about that, and didn't want to go so
far as to suggest a new thing to handle such options, but since there
is an older thing, that's handy. However, it seems like as-is it may
be too ugly to have is nested in an additional layer of quoting when
not being specified via environment variable. Does that seem like a
generally agreeable statement?

If that is the case, is there a convention we can use to separate the
parts of the connection string (in both representations) into the
parts sent to the server and the part that the client needs? We
already abuse this a little bit because URI syntax (in general, not
just our rendition of it) leaves little room for extension for
parameters on the client side. Consider ?sslmode=require.

In both representations, the net effect of a typo would be that
instead of magically reading some properties on the client side,
they'd be sent to the server. How often is this going to be so wrong
that one cannot send a response from the server indicating to the user
their error? On casual inspection it doesn't seem like prohibitively
often, but I haven't mulled over that for very long.

On that topic, the description of it in the libpq source is a little
bit mystifying, as I did see it but passed over it:

{"options", "PGOPTIONS", DefaultOption, NULL,
"Backend-Debug-Options", "D", 40},

If they're just options, what does this have to do with debugging? I
presumed some more specific purpose.

To end my email with a request for a pony, I think it'd be reasonable
to send these kinds of options again even while remaining connected.
One might be able appropriate "SET" statements to that purpose, but I
am not sure. This is mostly to the purpose of routing software, but I
could imagine other uses...

--
fdr