Re: Inconsistency in libpq connection parameters, and extension thereof

On Tue, Jun 5, 2012 at 9:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Daniel Farina <daniel(at)heroku(dot)com> writes:
>> Would these hypothetical extension-pairs be using the "options" device
>> at startup time, or something else (possibly brand new)?
>
> I'd argue for just translating them into "options", at least in the
> near term.  If they use some new mechanism then they would only work
> with new servers, and it's generally not good for libpq to assume much
> about what version of server it's working with, especially not when
> sending an initial connection packet (when, by definition, it can't
> know that for sure).
>
> As far as changing such settings later in the session is concerned,
> isn't that what SET is for?

Yeah; I mentioned that upthread. The only semantic difference I can
think of -- and this is a persnickety detail -- is that startup-time
options are evaluated all together. This is not unlike email or HTTP
headers as well.

The result is that if one expects to get several extension headers in
one shot that life is made more difficult. This can make validation
more tricky, but perhaps it could be fixed with a multi-set command,
should one not already exist.

Another issue is that it becomes more painful for proxies to
efficiently and easily pick out session value adjustments, as is
useful when composing them, so part of me would prefer to have a
protocol-level-only construct, but yet another part of me would really
like to just type "SET" into psql and try stuff. I guess it could be
a backslashified command, though...I wasn't looking to design this at
this time, but as long as you are willing to think and write about it,
I'm happy for the opportunity.

In the interest of unblocking a bit of exploratory work while
discussing this, perhaps we think a convention around "x-" or whatnot
and packing things into the PGOPTIONS makes sense?

--
fdr