From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Josh Berkus <josh@agliodbs.com>
Cc: John Proctor <jproctor@prium.net>
Cc: Neil Conway <nconway@klamath.dyndns.org>
Cc: peter_e@gmx.net
Cc: tgl@sss.pgh.pa.us
Cc: pgsql-patches@postgresql.org
Subject: Re: [SQL] 16 parameter limit
Date: Tue, 13 Aug 2002 22:48:12 -0400 (EDT)
Message-ID: <200208140248.g7E2mCF23367@candle.pha.pa.us> (raw)
In-Reply-To: <web-1374310@davinci.ethosmedia.com>
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@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: pgman@candle.pha.pa.us, josh@agliodbs.com, jproctor@prium.net, nconway@klamath.dyndns.org, peter_e@gmx.net, tgl@sss.pgh.pa.us, pgsql-patches@postgresql.org
Subject: Re: [SQL] 16 parameter limit
In-Reply-To: <200208140248.g7E2mCF23367@candle.pha.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox