From: | Andreas Zeugswetter <andreas(dot)zeugswetter(at)telecom(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: [SQL] aliases break my query |
Date: | 2000-05-28 07:34:40 |
Message-ID: | 00052809405405.00145@zeus |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-sql |
On Fri, 26 May 2000, Tom Lane wrote:
> "Zeugswetter Andreas" <andreas(dot)zeugswetter(at)telecom(dot)at> writes:
> > I think we could get agreement to not allow implicit from entries
> > if there is a from clause in the statement, but allow them if a from clause
> > is missing altogether. The patch did not distinguish the two cases.
>
> Hmm, that's a thought. Taking it a little further, how about this:
>
> "Emit a notice [or error if you insist] when an implicit FROM item is
> added that refers to the same underlying table as any existing FROM
> item."
>
> 95% of the complaints I can remember seeing were from people who got
> confused by the behavior of "FROM table alias" combined with a reference
> like "table.column". Seems to me the above rule would catch this case
> without being obtrusive in the useful cases. Comments?
I guess I would be more strict on the reason, that people playing with implicit
from entries usually know what they are doing, and thus know how to avoid a from
clause if they want that behavior. I don't see a reason to have one table in the
from clause but not another. This is too misleading for me.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Zeugswetter | 2000-05-28 08:12:23 | Re: Proposal for enhancements of privilege system |
Previous Message | Andreas Zeugswetter | 2000-05-28 07:30:38 | RE: Berkeley DB... |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Wickham | 2000-05-28 17:48:11 | plpgsql variable substitution problem ... |
Previous Message | Antony Sakellariou | 2000-05-27 20:03:58 | PL/pgSQL |