On 09.03.21 19:04, Tom Lane wrote:
> The implementation feels weird though, mainly in that I don't like
> Peter's choices for where to put the code. pquery.c is not where
> I would have expected to find the support for this, and I do not
> have any confidence that applying the format conversion while
> filling portal->formats[] is enough to cover all cases. I'd have
> thought that access/common/printtup.c or somewhere near there
> would be where to do it.
done
> Or we could drop all of that and go back to having it be a list
> of type OIDs, which would remove a *whole lot* of the complexity,
> and I'm not sure that it's materially less friendly. Applications
> have had to deal with type OIDs in the protocol since forever.
also done
The client driver needs to be able to interpret the OIDs that the
RowDescription sends back, so it really needs to be able to deal in
OIDs, and having the option to specify type names won't help it right now.
> BTW, I wonder whether we still need to restrict the GUC to not
> be settable from postgresql.conf. The fact that the client has
> to explicitly pass -1 seems to reduce any security issues quite
> a bit.
There was no security concern, but I don't think it's useful. The
driver would specify "send int4 in binary, I know how to handle that".
There doesn't seem to be a point in specifying that sort of thing globally.
