Hi, On 2017-06-08 23:05:53 -0400, Tom Lane wrote: > I spent some time experimenting with this, and immediately found out > that information_schema.user_mapping_options contains an instance of the > problematic usage :-(. However, that view also turns out to be a poster > child for why our old SRF semantics are a bad idea, because it's on the > hairy edge of failing completely. [...]
Yuck. > Anyway, to the subject at hand. My thought when I wrote the previous > message was to implement a "top down" mechanism whereby contexts like > CASE and COALESCE would record their presence in the ParseState while > recursively analyzing their arguments, and then SRF calls would be > responsible for throwing an error by inspecting that context. 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. > I'm inclined to go with the "bottom up" approach, but I wonder if anyone > has any comments or better ideas? I'll have a look at the patches tomorrow, but I'm too tired to meaningfully read code tonight. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
