"David G. Johnston" <david.g.johnston@xxxxxxxxx> writes:
> Based upon that unargued point the only bug here is in the documentation,
> leaving the reader to assume that some effort will be made to chain
> together a function returns clause to a physical table through that table's
> automatically-generated composite type.
Hmm, I read the documentation as making minimal promises about how
much effort will be expended, not maximal ones.
But in any case, I repeat the point that you can't open this can of
worms without having a lot of definitional slipperiness wriggle out.
Here is an example:
regression=# create table foo(a int, b int);
CREATE TABLE
regression=# create table bar(x int, y int, z int);
CREATE TABLE
regression=# create function f(int) returns setof foo stable
begin atomic select y, z from bar where x = $1; end;
CREATE FUNCTION
What labeling would you expect for "select * from f(...)",
and on what grounds? It is by no stretch of the imagination a
select from table foo. Moreover, the system has fully enough
information to perceive the query as a select from bar after
inlining the function call:
regression=# explain verbose select * from f(42);
QUERY PLAN
------------------------------------------------------------
Seq Scan on public.bar (cost=0.00..35.50 rows=10 width=8)
Output: bar.y, bar.z
Filter: (bar.x = 42)
(3 rows)
In fact, if we implemented this labeling at the tail end of
planning rather than early in parsing, it'd be fairly hard
to avoid labeling the output columns as bar.* rather than
foo.*. But we don't, and I'm not seeing an upside to
redefining how that works.
I've long forgotten the alleged JDBC connection that David
mentions, but it's surely just the tip of the iceberg of
client-side code that we could break if we change how this
works.
regards, tom lane
