Skip site navigation (1) Skip section navigation (2)

Re: Allow an alias for the target table in UPDATE/DELETE

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Allow an alias for the target table in UPDATE/DELETE
Date: 2006-01-22 15:22:12
Message-ID: 43D3A324.3020604@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-patches

Martijn van Oosterhout wrote:

>On Sun, Jan 22, 2006 at 09:04:14AM -0500, Andrew Dunstan wrote:
>  
>
>>>If you don't like relying on file order to resolve this, appropriate
>>>use of %prec would have the same effect (just like for operator
>>>precedence). The output file tell you which way bison went.
>>>      
>>>
>
>  
>
>>If we allow shift/reduce or reduce/reduce conflicts, debugging future 
>>development becomes more difficult. Right now we have the nice property 
>>that if you see one of those you know you've done something wrong (and 
>>using the expect directive isn't really a good answer, and only applies 
>>to shift/reduce conflicts anyway).
>>    
>>
>
>But that's the point of the %prec directive. To force bison to choose
>one or the other, thus removing the warning... For an ambiguity that
>only appears in one statement, it seems a better solution than upgrade
>SET to a new class of identifier.
>
>  
>

Quite so. We already use %prec extensively. All I was pointing out was 
that using file order isn't an acceptable option.

Presumably the effect in this case would be to prevent anyone from using 
SET as an alias unless there was a preceding AS.

cheers

andrew



In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2006-01-22 18:26:23
Subject: Re: Allow an alias for the target table in UPDATE/DELETE
Previous:From: Martijn van OosterhoutDate: 2006-01-22 15:06:30
Subject: Re: Allow an alias for the target table in UPDATE/DELETE

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group