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
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 |
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 |
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 |