Re: PostgreSQL 9.6 behavior change with set returning (funct).*

On Wed, Mar 23, 2016 at 3:18 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> I have to side with what I believe is Tom's position on this one. I do
> like the notion of throwing an error in cases where someone sent us
> something that we're pretty sure is wrong, but I don't agree that we
> should continue to carry on bug-compatibility with things that are
> already one foot in the grave and really just need to be shoved all the
> way in.

Well, the fact that it turns out to be 2+ SRF, not just 1 as a trigger
has significantly lowered my alarm. I agree that such usages are tiny
and the LCM way of determining rows is definitely bizarre. Don't
believe me? Try figuring out when

select generate_series(1,nextval('s')), generate_series(1,nextval('s'));

terminates. (hint: it doesn't). Another cute multiple SRF
invocation: http://merlinmoncure.blogspot.com/2007/12/12-days-of-christmas-postgresql-style.html
:-)

> This isn't the only break in backwards compatibility we've had over the
> years and is pretty far from the largest (string escaping, anyone? or
> removing implicit casts?) and I'd argue we're better off for it.

String escaping was an unmitigated disaster. Implict cast removal cost
my company a couple of hundred thousand bucks and came within a hair
of pushing postgres out completely (not that I'm complaining, we're
the better for that but these decisions must not be taken lightly).
Things are different now.

On Wed, Mar 23, 2016 at 5:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> (The SRF invocations might be buried inside expressions, but we'd find
> them and convert them anyway. Also, we'd merge textually-identical SRF
> invocations into a single ROWS FROM entry to avoid multiple evaluation,
> at least for SRFs not marked volatile.) Having done that, the executor's
> support for SRFs in general expressions could be removed, a significant
> savings.

That's just brilliant -- I'd be on board with that FWIW.

merlin