Re: Re: [SQL] aliases break my query

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

In response to

Browse pgsql-hackers by date

  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...

Browse pgsql-sql by date

  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