Andres Freund <and...@anarazel.de> writes: > On 2017-06-08 23:05:53 -0400, Tom Lane wrote: >> ... The first >> attached patch does it that way, and it seems nice and clean, but I ran >> into a complete dead end while trying to extend it to handle related cases >> such as disallowing SRF-inside-aggregate or nested SRFs in FROM.
> But, do we really need to handle those? IOW, isn't handling > CASE/COALESCE, which we can recognize early in parse analysis, > sufficient to error out here? It'd be a lot nicer if we could error > about SRF arguments to aggregates et al. during analysis rather than > execution, but there's not a comparably huge need to improve there. Yes, we already have guards for those cases, but they return fairly opaque error messages to the tune of "set-valued function called in context that cannot accept a set", because the executor hasn't enough context to do better. I'd like the messages to be more specific, like "set-valued function cannot appear within CASE" and so on. Anyway the point here is to evaluate different approaches to changing the parser on the basis of whether they *could* be extended to handle related cases. Whether we actually do that right now is less important. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers