Re: Common Table Expressions applied; some issues remain

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Yoshiyuki Asaba <y-asaba(at)sraoss(dot)co(dot)jp>, Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Common Table Expressions applied; some issues remain
Date: 2008-10-05 15:19:33
Message-ID: 2500.1223219973@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> Tom Lane wrote:
>>> 2. The patch didn't touch the implicit-RTE code, which means that
>>>
>>> WITH q AS ( SELECT ... )
>>> SELECT q.*
>>>
>>> will fail even if you've got add_missing_from enabled.
>>
>> Yes, it's legacy. I wouldn't bother.

> The results would be even more suprising if there *is* a table named "q"
> though...

Yeah, the real problem is not so much that it might fail as that it
might silently do something quite different from what you would expect.

CVS HEAD documentation states

(In fact, the WITH query hides any real table of the same name for the
purposes of the primary query. If necessary, you can refer to a real
table of the same name by schema-qualifying the table's name.)

If we don't fix this, I think we'd have to add some disclaimer about
how WITH clauses *don't* hide real tables in the case of implicit RTE
additions. That seems much uglier than fixing it.

(Hmm, memo to self: I'll bet ruleutils.c's decision about whether it
needs to schema-qualify a reverse-listed table name doesn't take this
into account.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-10-05 15:41:21 Re: CYCLE and SEARCH [was Re: Common Table Expressions (WITH RECURSIVE) patch]
Previous Message Tom Lane 2008-10-05 15:02:44 Re: db_user_namespace, md5 and changing passwords