Dean Rasheed <dean.a.rash...@gmail.com> writes:
> On 3 December 2013 23:37, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Thinking some more about bug #8648, it occurred to me that ruleutils.c
>> isn't exactly prepared for the case either:
>> ... So I'm leaning towards just doing
>>
>> + if (colno == 0)
>> + appendStringInfoString(buf, " *");
>>
>> at least till such time as somebody shows a case where this isn't good
>> enough.
> Well here's a contrived example with grouping:
> create table nocols();
> create table somecols(a int, b int);
> create view v as select exists(select nocols.* from nocols, somecols
> group by somecols.a);
Hm, that's cute :-(. And I realized last night that my patch's approach
of seizing on some random zero-column RTE isn't too bulletproof against
ALTER TABLE ADD COLUMN operations, either, ie, the referenced table might
have some columns by now. Which is more or less the entire reason we
expand "*" at parse time in the first place.
What I'm thinking about this today is that really the *right* solution
is to allow syntactically-empty SELECT lists; once we've bought into the
notion of zero-column tables, the notion that you can't have an empty
select list is just fundamentally at odds with that. And since you can
already have semantically-empty SELECT lists, this should in theory not
create much risk of new bugs. If we did that, the existing ruleutils
code is just fine, as are any existing dump files containing this sort
of query.
That change might still be thought too aggressive for a back-patch,
though. Comments?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
