Robert Haas <robertmh...@gmail.com> writes: > On Tue, Sep 12, 2017 at 1:37 PM, Tom Lane <t...@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