Re: default result formats setting

On 2020-10-26 15:35, Tom Lane wrote:
>> In the discussion in [0], I pondered a new protocol message for that,
>> but after further thought, a GUC setting would do just as well.
>
> I think a GUC is conceptually the wrong level ...

It does feel that way, but it gets the job done well and you can use all
the functionality already existing, such as being able to inspect
settings, temporarily change settings, etc. Otherwise we'd have to
implement a lot of things like that again. That would turn this 200
line patch into a 2000 line patch without any real additional benefit.

>> In order to be able to test this via libpq, I had to add a little hack.
>
> ... which is part of the reason why you have to kluge this. I'm not
> entirely certain which levels of the client stack need to know about
> this, but surely libpq is one.
>
> I'm also quite worried about failures (maybe even security problems)
> arising from the "wrong level" of the client stack setting the GUC.

I don't think libpq needs to know about this very deeply. The protocol
provides format information with the result set. Libpq programs can
query that with PQfformat() and act accordingly. Nothing else is needed.

The real consumer of this would be the JDBC driver, which has built-in
knowledge of the binary formats of some data types. Libpq doesn't, so
it wouldn't use this facility anyway. (Not saying someone couldn't
write a higher-level C library that does this, but it doesn't exist now.
... hmm ... ecpg ...)

> Independently of that, how would you implement "says otherwise" here,
> ie do a single-query override of the session's prevailing setting?
> Maybe the right thing for that is to define -1 all the way down to the
> protocol level as meaning "use the session's per-type default", and
> then if you don't want that you can pass 0 or 1. An advantage of that
> is that you couldn't accidentally break an application that wasn't
> ready for this feature, because it would not be the default to use it.

Yeah, that sounds a lot better. I'll look into that.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services