Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Sep 12, 2017 at 1:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The trick here is that I don't think we want to change the returned column
>> types for queries that are not being sent to a client. The parser and
>> planner aren't really aware of that context ATM. Maybe we could make them
>> so?
> I guess it depends on whether that context is mutable. Can I Parse a
> query to create a prepared statement, then use that from a stored
> procedure? If so, then it's not firmly known at plan time what the
> execution context will be.
Um, good point; I'm pretty sure that we don't distinguish. This may
well be the reason it's done like this right now.
>> I wonder if it'd help to put some kind of bespoke cache into getBaseType.
>> We've done that elsewhere, eg operator lookup.
> That might be a possibility, although I feel like it's likely to be
> substantially less effective than the quick hack, and it's not really
> attacking the problem at the root anyway.
I'd say that what you're proposing is the exact opposite of attacking
the problem at the root.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers