diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2016-07-26 21:33:49 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2016-07-26 21:34:02 -0400 |
commit | d8411a6c8b6e5f74b362ef2496723f7f88593737 (patch) | |
tree | 7caa18bedeccfa64310ea6b790a0bafcb2c87f44 /src/backend/access/gist/gistvalidate.c | |
parent | 976b24fb477464907737d28cdf18e202fa3b1a5b (diff) | |
download | postgresql-d8411a6c8b6e5f74b362ef2496723f7f88593737.tar.gz |
Allow functions that return sets of tuples to return simple NULLs.
ExecMakeTableFunctionResult(), which is used in SELECT FROM function(...)
cases, formerly treated a simple NULL output from a function that both
returnsSet and returnsTuple as a violation of the SRF protocol. What seems
better is to treat a NULL output as equivalent to ROW(NULL,NULL,...).
Without this, cases such as SELECT FROM unnest(...) on an array of
composite are vulnerable to unexpected and not-very-helpful failures.
Old code comments here suggested an alternative of just ignoring
simple-NULL outputs, but that doesn't seem very principled.
This change had been hung up for a long time due to uncertainty about
how much we wanted to buy into the equivalence of simple NULL and
ROW(NULL,NULL,...). I think that's been mostly resolved by the discussion
around bug #14235, so let's go ahead and do it.
Per bug #7808 from Joe Van Dyk. Although this is a pretty old report,
fixing it smells a bit more like a new feature than a bug fix, and the
lack of other similar complaints suggests that we shouldn't take much risk
of destabilization by back-patching. (Maybe that could be revisited once
this patch has withstood some field usage.)
Andrew Gierth and Tom Lane
Report: <E1TurJE-0006Es-TK@wrigleys.postgresql.org>
Diffstat (limited to 'src/backend/access/gist/gistvalidate.c')
0 files changed, 0 insertions, 0 deletions