Daniel Farina <daniel@heroku.com> writes:
> On Tue, Jun 5, 2012 at 6:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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?
Yeah, I was wondering the same thing. The current syntax for options
certainly carries plenty of historical baggage. The main point here
IMO is that libpq should have some way of telling parameters-for-the-
server from things that are meant to be its own parameters.
> 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?
Rather than imagining this as two parts of the connection string,
I think it would be nicer if we could have a convention that modifies
the names of server-side parameters. In the connection string syntax
we could perhaps do something like
'host=localhost dbname=foo x:param=value1 x:anotherparam=value2'
This preserves the benefits of order-independence of the items, and
seems at least a little bit more able to recognize typos than your
original concept. I don't know if the specific notation "x:" would
translate well into URI notation, but if not that, maybe there's
something else that would.
> 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?
If you misspell "host" for instance, you've got a problem. More
generally, if you misspell "user" or "dbname" you're likely to get
an authentication-related error that would not be at all helpful at
leading your mind to the problem. (And it's not like these things
are so consistently named that nobody ever gets 'em wrong...)
I would not expect the server to start examining optional parameters
until the connection has been successfully authenticated, so any
typo in the basic connection properties is going to lead to unhelpful
behavior if it causes us to think the item is an optional parameter
rather than a misspelled one.
regards, tom lane