Re: Inconsistency in libpq connection parameters, and extension thereof

On Tue, Jun 5, 2012 at 8:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

I agree with this.

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

How about "x-param=foo&x-anotherparam=bar"? I think this could work
in the connection syntax as well: "host=localhost x-param=value1".

It doesn't scan as visibly as ":", but probably will cause less
escaping pain across the board. It also looks a lot like a
lower-cased HTTP header or email-header, so people might make the
right association right away.

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

Well, I wonder if there's a way to mitigate that, but I think as long
as we're satisfied thus far with a prefix there's no need to talk
about this particular thorn, as it can be considered sidestepped.

If we go so far as to namespace with something like "x:" or "x-" and
to have such a rigorous concept of extension in protocol related
matters, we're in a good place to have a nice cohesive expansion (at
some later time) into more "x-..." headers exchanged between host in
client mid-communication, beyond just startup. At some later date.

Would these hypothetical extension-pairs be using the "options" device
at startup time, or something else (possibly brand new)? I'm not
ideally informed as to contemplate on if reuse of an existing thing
makes sense.

--
fdr