From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stuart Rison <stuart(at)ludwig(dot)ucl(dot)ac(dot)uk> |
Cc: | mdalphin(at)amgen(dot)com, pgsql-sql(at)postgreSQL(dot)org |
Subject: | Re: [SQL] Anyone recognise this error from PL/pgSQL? |
Date: | 1999-08-16 14:12:11 |
Message-ID: | 632.934812731@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Stuart Rison <stuart(at)ludwig(dot)ucl(dot)ac(dot)uk> writes:
> Yes, I remember a posting about this a little while ago, the solution was
> so simple it made you want to kick yourself!
> SELECT * INTO zhvt_row FROM zhvt
> WHERE zhvtID=NEW.zhvtID;
> Becomes:
> SELECT * INTO zhvt_row FROM zhvt
> WHERE zhvtID = NEW.zhvtID; --spaces on either side of the equal
> I'm wondering if this is a bug that should be corrected in the parser or if
> it is correct syntax for the operator to be bound by spaces?
I thought it might be something like that ... probably plpgsql
transforms "NEW" into something involving a "$" and then the parser
misparses "=$" as a single operator. I'd argue that it's a plpgsql bug,
if that's right --- if plpgsql is doing text transformations that create
lexical ambiguities, it should be inserting spaces to prevent ambiguity.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stuart Rison | 1999-08-16 14:57:27 | Re: [SQL] Anyone recognise this error from PL/pgSQL? |
Previous Message | Dionisio Barrantes | 1999-08-16 09:55:56 | unsuscribe |