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
On Sun, 2006-01-22 at 13:43 -0500, Tom Lane wrote:
I object ... this is still trying to enforce tupdesc refcounting on much
more of the system than I think useful or prudent.
Well, the patch adds management of TupleDesc refcounts solely for the
return value of lookup_rowtype_tupdesc(). If we're
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.
Hi,
it's a renewed locale per database patch. Unfortunately, i've not found
clean way to rebuild database indexes automatically, if locale settings
of two databases (created and template) are differs. Now it's only
raises a NOTICE. So, if anyone has a right notion about it - let will
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
