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 h
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 ha
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
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 whe
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
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
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 qua
"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 th
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 emp.e
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
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
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 su
12 matches
Mail list logo
