Re: [SQL] 16 parameter limit

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: John Proctor <jproctor(at)prium(dot)net>, Neil Conway <nconway(at)klamath(dot)dyndns(dot)org>, peter_e(at)gmx(dot)net, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-patches(at)postgresql(dot)org
Subject: Re: [SQL] 16 parameter limit
Date: 2002-08-14 02:48:12
Message-ID: 200208140248.g7E2mCF23367@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches pgsql-sql


Added:

o Allow array declarations and other data types in PL/PgSQl
DECLARE
o Add PL/PgSQL PROCEDURES that can return multiple values

> Also:
>
> 10) Allow declaration of all PostgreSQL data types, including custom
> data types and domains, inside functions. Especially important are
> Arrays, which are supported as parameters but not as declarations.

Added

> 11) PL/pgSQL has functionality 100% analagous to cursors, with a
> different syntax. While the PL/pgSQL record loop is easier to use, the
> lack of support for standard cursor syntax mars the poratbility of
> Oracle procedures to Postgres and vice-versa.

Is this done?

>
> 12) The biggie: Allowing the easy return of query results from a
> procedure. This is currently supported through a rather difficult
> workaround involving either the ROWTYPE datatype or a return Cursor.
> Both approaches require the use of a procedural code loop on the
> interface side to read the data being returned ... much clumsier than
> just dumping the data ala PL/SQL or T-SQL. If implemented, this rowset
> return would the the difference between a CREATE FUNCTION and a CREATE
> PROCEDURE statement.

Done for 7.3.

>
> 13) Allow the creation of multiple output parameters for PROCEDURES (as
> opposed to FUNCTIONS) in the parameter declaration.

Added.

> 14) Procedures should have their own permissions, which supercede the
> permissions on the tables being affected if the procedure is created by
> the database owner, in the same way that Views can allow users to
> Select data they would not be entitled to from the base tables. In
> other words, if I declare "GRANT SELECT ON fn_modify_assignment TO
> phpaccess", the user phpaccess should be able to run
> fn_modify_assignment even if that user has no permissions on the
> assignment table itself.

Done, I think, for 7.3.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2002-08-14 02:52:24 Re: [HACKERS] SQL99 CONVERT() function
Previous Message Hannu Krosing 2002-08-14 02:47:06 Re: Inheritance

Browse pgsql-patches by date

  From Date Subject
Next Message Tatsuo Ishii 2002-08-14 02:52:24 Re: [HACKERS] SQL99 CONVERT() function
Previous Message Bruce Momjian 2002-08-14 02:43:18 Re: [SQL] 16 parameter limit

Browse pgsql-sql by date

  From Date Subject
Next Message Joe Conway 2002-08-14 03:28:52 Re: [SQL] 16 parameter limit
Previous Message Bruce Momjian 2002-08-14 02:43:18 Re: [SQL] 16 parameter limit