Re: default result formats setting - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: default result formats setting
Date
Msg-id 038ba58d-0838-99dc-b8ae-a956f66a6597@2ndquadrant.com
Whole thread Raw
In response to Re: default result formats setting  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: default result formats setting  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: default result formats setting
Next
From: David Rowley
Date:
Subject: Re: Reduce the number of special cases to build contrib modules on windows