Thread: 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.php
>
>         o 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 functions
>
>           http://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