pgsql: Clarify dynamic pl/pgsql item and add URLs.
Log Message:
-----------
Clarify dynamic pl/pgsql item and add URLs. Restructure server-side
section into PL/pgSQL and non-PL/pgSQL sections:
< o Fix PL/pgSQL RENAME to work on variables other than OLD/NEW
< o Allow function parameters to be passed by name,
< get_employee_salary(emp_id => 12345, tax_year => 2001)
< o Add Oracle-style packages
< o Add table function support to pltcl, plpython
< o Add capability to create and call PROCEDURES
< o Allow PL/pgSQL to handle %TYPE arrays, e.g. tab.col%TYPE[]
< o Allow function argument names to be statements from PL/PgSQL
< o Add MOVE to PL/pgSQL
< o Add support for polymorphic arguments and return types to
< languages other than PL/PgSQL
< o Add support for OUT and INOUT parameters to languages other
< than PL/PgSQL
< o Add single-step debugging of PL/PgSQL functions
< o Allow PL/PgSQL to support WITH HOLD cursors
< o Allow PL/PgSQL RETURN to return row or record functions
<
< http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php
o PL/pgSQL
o Fix RENAME to work on variables other than OLD/NEW
o Allow function parameters to be passed by name,
get_employee_salary(emp_id => 12345, tax_year => 2001)
o Add Oracle-style packages
o Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]
o Allow listing of record column names, and access to
record columns via variables, e.g. columns := r.(*),
tval2 := r.(colname)http://archives.postgresql.org/pgsql-patches/2005-07/msg00458.php
http://archives.postgresql.org/pgsql-patches/2006-05/msg00302.php
http://archives.postgresql.org/pgsql-patches/2006-06/msg00031.phpo Add MOVE
o Add single-step debugging of functions
o Add support for WITH HOLD cursors
o Allow PL/RETURN to return row or record functionshttp://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php
o Other
o Add table function support to pltcl, plpython
o Add support for polymorphic arguments and return types to
languages other than PL/PgSQL
o Add capability to create and call PROCEDURES
o Add support for OUT and INOUT parameters to languages other
than PL/PgSQL
Modified Files:
--------------
pgsql/doc:
TODO (r1.1878 -> r1.1879)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/TODO.diff?r1=1.1878&r2=1.1879)
pgsql/doc/src/FAQ:
TODO.html (r1.381 -> r1.382)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/FAQ/TODO.html.diff?r1=1.381&r2=1.382)
momjian@postgresql.org (Bruce Momjian) writes:
o Allow function parameters to be passed by name,
get_employee_salary(emp_id => 12345, tax_year => 2001)
The odds of that syntax getting accepted may not be exactly zero, but
they are certainly vanishingly small. I thought we'd agreed that a
usable syntax would be like
get_employee_salary(12345 AS emp_id, 2001 AS tax_year)
regards, tom lane
Tom Lane wrote:
momjian@postgresql.org (Bruce Momjian) writes:
o Allow function parameters to be passed by name,
get_employee_salary(emp_id => 12345, tax_year => 2001)The odds of that syntax getting accepted may not be exactly zero, but
they are certainly vanishingly small. I thought we'd agreed that a
usable syntax would be like
get_employee_salary(12345 AS emp_id, 2001 AS tax_year)
TODO updated, but I thought "=>" was the Oracle syntax.
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
On Thu, Jun 15, 2006 at 01:42:10PM -0400, Bruce Momjian wrote:
Tom Lane wrote:
momjian@postgresql.org (Bruce Momjian) writes:
o Allow function parameters to be passed by name,
get_employee_salary(emp_id => 12345, tax_year => 2001)The odds of that syntax getting accepted may not be exactly zero,
but they are certainly vanishingly small. I thought we'd agreed
that a usable syntax would be like get_employee_salary(12345 AS
emp_id, 2001 AS tax_year)TODO updated, but I thought "=>" was the Oracle syntax.
It is. I understand Tom's concern about not unnecessarily grabbing
operator symbols, but in this case, I believe it's overblown.
Cheers,
D
--
David Fetter <david@fetter.org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter
Remember to vote!
David Fetter wrote:
On Thu, Jun 15, 2006 at 01:42:10PM -0400, Bruce Momjian wrote:
Tom Lane wrote:
momjian@postgresql.org (Bruce Momjian) writes:
o Allow function parameters to be passed by name,
get_employee_salary(emp_id => 12345, tax_year => 2001)The odds of that syntax getting accepted may not be exactly zero,
but they are certainly vanishingly small. I thought we'd agreed
that a usable syntax would be like get_employee_salary(12345 AS
emp_id, 2001 AS tax_year)TODO updated, but I thought "=>" was the Oracle syntax.
It is. I understand Tom's concern about not unnecessarily grabbing
operator symbols, but in this case, I believe it's overblown.
Interesting. Seems it is something we will have to discuss when we get
closer to a patch.
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Tom Lane wrote:
The odds of that syntax getting accepted may not be exactly zero, but
they are certainly vanishingly small. I thought we'd agreed that a
usable syntax would be like
get_employee_salary(12345 AS emp_id, 2001 AS tax_year)
TODO updated, but I thought "=>" was the Oracle syntax.
So? We don't support Oracle's brain-dead outer join syntax either.
regards, tom lane
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
Tom Lane wrote:
The odds of that syntax getting accepted may not be exactly zero, but
they are certainly vanishingly small. I thought we'd agreed that a
usable syntax would be like
get_employee_salary(12345 AS emp_id, 2001 AS tax_year)TODO updated, but I thought "=>" was the Oracle syntax.
So? We don't support Oracle's brain-dead outer join syntax either.
We had reasonable problems with Oracle's outer-join syntax, while I
don't see the same fundamental issue with => vs AS, and PL/pgSQL is
patterned on Oracle's PL/SQL.
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <pgman@candle.pha.pa.us> writes:
We had reasonable problems with Oracle's outer-join syntax, while I
don't see the same fundamental issue with => vs AS, and PL/pgSQL is
patterned on Oracle's PL/SQL.
The fundamental issue is reserving what used to be an available operator
name, in the service of a syntax that's not got anything to recommend
it other than being Oracle-compatible. AS is already a fully reserved
word, so we'd be taking no risk of breaking anyone's app if we use it.
And plpgsql has got nothing to do with this, because we're talking SQL
syntax not plpgsql.
regards, tom lane