Another possibility is to disallow SET here, but not in other places
where ColId is used. That is, some hack like:
Quick point: If all you want to do if disallow SET here as ColID but
allow SET in other places with a ColId, you don't have to change
anything at all. Just make sure the rule for
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.
Andrew Dunstan [EMAIL PROTECTED] writes:
Presumably the effect in this case would be to prevent anyone from using
SET as an alias unless there was a preceding AS.
I fooled around with this and found three feasible alternatives.
The simplest thing is:
relation_expr_opt_alias: relation_expr
Tom Lane wrote:
The effect of this, as Andrew says, is that in this particular context
you can't write SET as an alias unless you write AS first. This is
probably not going to surprise anyone in the UPDATE case, since the
ambiguity inherent in writing
UPDATE foo set SET ...
is pretty
On Sun, 2006-01-22 at 13:26 -0500, Tom Lane wrote:
The effect of this, as Andrew says, is that in this particular context
you can't write SET as an alias unless you write AS first.
Did you actually test this?
neilc=# create table t1 (a int, b int);
CREATE TABLE
neilc=# update t1 set set a =
Neil Conway [EMAIL PROTECTED] writes:
Did you actually test this?
No, I was just looking at the y.output file to see what would happen.
neilc=# update t1 set set a = 500 where set.a 1000;
UPDATE 0
(Using essentially the patch you posted.)
[ scratches head... ] That shouldn't have worked.
Neil Conway [EMAIL PROTECTED] writes:
Did you actually test this?
neilc=# create table t1 (a int, b int);
CREATE TABLE
neilc=# update t1 set set a = 500 where set.a 1000;
UPDATE 0
I get
regression=# update t1 set set a = 500 where set.a 1000;
ERROR: syntax error at or near a at
On Sat, 2005-12-03 at 10:42 +0900, Atsushi Ogawa wrote:
Thanks for comments. I modified the patch.
Patch applied to HEAD.
From looking at SQL2003, it seems to me that this syntax is actually
specified by the standard:
update statement: searched ::=
UPDATE target table [ [ AS ] correlation
Neil Conway [EMAIL PROTECTED] writes:
From looking at SQL2003, it seems to me that this syntax is actually
specified by the standard:
update statement: searched ::=
UPDATE target table [ [ AS ] correlation name ]
SET set clause list
[ WHERE search condition ]
delete statement:
Neil Conway [EMAIL PROTECTED] writes:
Patch applied to HEAD.
This is wrong:
+relation_expr_opt_alias: relation_expr
+ {
+ $$ = $1;
+ }
+ | relation_expr opt_as IDENT
+
On Sun, 2006-01-22 at 00:55 -0500, Tom Lane wrote:
This is wrong:
+relation_expr_opt_alias: relation_expr
+ {
+ $$ = $1;
+ }
+ | relation_expr opt_as IDENT
+
Neil Conway [EMAIL PROTECTED] writes:
On Sun, 2006-01-22 at 00:55 -0500, Tom Lane wrote:
Should be ColId, not IDENT, per existing alias_clause production.
That causes a reduce/reduce conflict:
The grammar change is the one marginally nontrivial part of the patch,
and you couldn't be bothered
On Sun, 2006-01-22 at 01:28 -0500, Tom Lane wrote:
The grammar change is the one marginally nontrivial part of the patch,
and you couldn't be bothered to get it right? Try harder.
:-(
I believe the conflict results from the fact that ColId can include SET
(since it is an unreserved_keyword),
Neil Conway [EMAIL PROTECTED] writes:
Can you see a better fix?
I haven't done any experimentation, but my first instinct would be to
spell out the productions at greater length: instead of
relation_expr opt_as ColId
try
relation_expr ColId
| relation_expr AS ColId
On Sun, 2006-01-22 at 02:05 -0500, Neil Conway wrote:
I believe the conflict results from the fact that ColId can include SET
(since it is an unreserved_keyword), but SET might also be the next
token in the UpdateStmt, and yacc is not capable of distinguishing
between these two cases. We could
On Sun, 2006-01-22 at 02:23 -0500, Tom Lane wrote:
relation_expr opt_as ColId
try
relation_expr ColId
| relation_expr AS ColId
Yeah, I already tried that without success. The no-AS-specified variant
is still ambiguous: given SET following relation_expr, the parser still
Thanks for comments. I modified the patch.Tom Lane wrote: Atsushi Ogawa [EMAIL PROTECTED] writes: (2)About processing when column identifier of SET clause is specified
like 'AAA.BBB'. 'AAA' is a composite column now. When an alias for target table is supported, 'AAA' is a composite column or a
I made a patch to allow an alias for target table in UPDATE/DELETE
This is a TODO item.
o Allow an alias to be provided for the target table in UPDATE/DELETE
This is not SQL-spec but many DBMSs allow it.
Example:
UPDATE accounts AS a SET a.abalance = a.abalance + 10 WHERE a.aid = 1;
I think
18 matches
Mail list logo
