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