Added to pl/pgsql TODO:
o Improve logic of determining if an identifier is a a
variable or column name
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00436.php
---
Tom Lane wrote:
I
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Tom Lane wrote:
I have just absorbed the significance of some code that has been in
plpgsql since day one, but has
On Sat, 2007-07-14 at 19:52 -0400, Tom Lane wrote:
Affan Salman [EMAIL PROTECTED] writes:
Could we not, at least, support explicit column disambiguation?
The problem is that there are places in the SQL grammar where we don't
allow qualification of a SQL name --- INSERT column lists, UPDATE
I wrote:
... In at least those three cases, we know that it's not sensible to
substitute a parameter. If that's true in all the problem cases,
which seems likely, then we could do something with Greg's idea
of using the raw parse tree from the main SQL parser to guide
decisions about where
Anyway it seems like this whole area is a research project for 8.4
or later, not something we should try to fix now. But having said
that, there didn't seem to be any objection to the idea of changing
the outer block (where function parameters are declared) to be labeled
with the function name,
I have just absorbed the significance of some code that has been in
plpgsql since day one, but has never been documented anyplace.
It seems that if you attach a label to a statement block in a
plpgsql function, you can do more with the label than just use it in
an EXIT statement (as I'd always
Tom Lane wrote:
Anyway, I'm not writing just to point out that we have a previously
undocumented feature. I notice that the section on porting from Oracle
PL/SQL mentions
You cannot use parameter names that are the same as columns that are
referenced in the function. Oracle allows you
Heikki Linnakangas [EMAIL PROTECTED] writes:
ISTM supporting somefunc.ambiguous just gives us another way to
reference the parameter, and there still isn't any way to refer the column.
Sure. All this will do is let us remove a noted incompatibility with
Oracle, which seems worth doing if it's
ISTM supporting somefunc.ambiguous just gives us another way to
reference the parameter, and there still isn't any way to refer the
column.
Could we not, at least, support explicit column disambiguation?
e.g. This PL/SQL procedure:
CREATE OR REPLACE PROCEDURE insert_emp (empno
Affan Salman [EMAIL PROTECTED] writes:
Could we not, at least, support explicit column disambiguation?
The problem is that there are places in the SQL grammar where we don't
allow qualification of a SQL name --- INSERT column lists, UPDATE SET
targets, and SELECT AS labels are three I can think
Anyway, I'm not writing just to point out that we have a previously
undocumented feature. I notice that the section on porting from Oracle
PL/SQL mentions
You cannot use parameter names that are the same as columns that are
referenced in the function. Oracle allows you to do this if you
In at least those three cases, we know that it's not sensible to
substitute a parameter. If that's true in all the problem cases,
which seems likely, then we could do something with Greg's idea
of using the raw parse tree from the main SQL parser to guide
decisions about where parameters may be
12 matches
Mail list logo
