Обсуждение: Re: [HACKERS] Table aliases in delete statements?

Brian E Gallew <geek+@cmu.edu>
>Then <tgl@sss.pgh.pa.us> spoke up and said:
>> Keith Parks <emkxp01@mtcc.demon.co.uk> writes:
>> > Is there any reason for not allowing table aliases in
>> > delete statements?
>> 
>> As Bruce points out in another followup, there's no real need for
>> an alias for the target table; if you have sub-selects that need
>> independent references to the target, you can always alias *them*.
>> The same goes for INSERT and UPDATE, which also take unadorned
>> <table name> as the target table specification.
>
>Unless your query is going to be long enough to run into query length
>limits, aliases are not your friends.  Standard SQL they may be, but
>aliases always end up obscuring queries to those who come along after
>you. 

The problem is that it's difficult to refer to the same table twice
in a single query without using aliases.

The trap I fell into was thinking I had to alias both references to
the table.

I'd be interested in seeing alternative solutions to the duplicate
removal problem.

Keith.

> >Unless your query is going to be long enough to run into query length
> >limits, aliases are not your friends.  Standard SQL they may be, but
> >aliases always end up obscuring queries to those who come along after
> >you. 
> 
> The problem is that it's difficult to refer to the same table twice
> in a single query without using aliases.
> 
> The trap I fell into was thinking I had to alias both references to
> the table.
> 
> I'd be interested in seeing alternative solutions to the duplicate
> removal problem.

Yes, that is tricky in that there is an aliased version and a non-alias
version of the same table.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026