Daniel Farina <daniel@heroku.com> writes:
> Similar in purpose to cc3f281ffb0a5d9b187e7a7b7de4a045809ff683, but
> taking into account that a dblink caller may choose to cause arbitrary
> changes to DateStyle and IntervalStyle. To handle this, it is
> necessary to use PQparameterStatus before parsing any input, every
> time. This is avoided in cases that do not include the two
> problematic types treated -- interval and timestamptz -- by scanning
> the TupleDesc's types first.
Hm. Is that really a win? Examining the tupdesc wouldn't be free
either, and what's more, I think you're making false assumptions about
which types have behavior dependent on the GUCs. You definitely missed
out on date and plain timestamp, and what of domains over these types?
I'd be inclined to eat the cost of calling PQparameterStatus every time
(which won't be that much) and instead try to optimize by avoiding the
GUC-setting overhead if the current value matches the local setting.
But even that might be premature optimization. Did you do any
performance testing to see if there was a problem worth avoiding?
> Although it has been suggested that extra_float_digits would need
> similar treatment as IntervalStyle and DateStyle (as it's seen in
> pg_dump), extra_float_digits is not an GUC_REPORT-ed GUC and is not
> able to be checked in PQparameterStatus, and furthermore, the float4
> and float8 parsers are not sensitive to the GUC anyway: both accept as
> much precision as is provided in an unambiguous way.
Agreed, we don't need to worry so much about that one; or at least,
if we do need to worry, it's on the other end of the connection from
what we're fixing here.
regards, tom lane
