Skip site navigation (1) Skip section navigation (2)

Re: Proposal: real procedures again (8.4)

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Josh Berkus <Josh(dot)Berkus(at)sun(dot)com>, David Fetter <david(at)fetter(dot)org>
Subject: Re: Proposal: real procedures again (8.4)
Date: 2007-11-05 03:51:01
Message-ID: 200711050351.lA53p1R07663@momjian.us (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-hackers
This has been saved for the 8.4 release:

	http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

Pavel Stehule wrote:
> Hello,
> 
> I found lot of discus about this topic.
> 
> http://www.postgresql.org/docs/faqs.TODO.html
> http://archives.postgresql.org/pgsql-hackers/2003-08/msg00501.php
> http://archives.postgresql.org/pgsql-hackers/2004-09/msg00734.php
> http://archives.postgresql.org/pgsql-hackers/2004-08/msg00872.php
> http://archives.postgresql.org/pgsql-hackers/2004-09/msg00702.php
> 
> There is one result - OUT params for functions. I propose start with
> simple goals that we can enhance in future.
> 
> First goal: Procedures support for better conformance with ANSI SQL:
> 
> * procedure returns any only through OUT, INOUT params,
> * procedure has own executor, that allows byref params (and own
> transaction management in future),
> * procedure can be overloaded,
> * procedure can not returns recordset or multi recordset,
> * procedure doesn't support default parameters,
> * SQL statement CALL allows only expression (this proposal doesn't
> need session variables) for older environments
> * new SPI_exec_procedures API (allows binding to host variables) and
> some similar in libpq, that allow CALL implementation in pgsql and
> others.
> * new internal exec_exec_proc (allow ref on datum variable) used in
> plpgsql statement CALL.
> * new V2 calling convention (maybe based on SQL/CLI)
> * no changes in current functions support
> 
> Later:
> * procedure can manages transactions,
> * procedure can returns recordset or multi recordset,
> * procedure allows default parameters,
> * CALL statement allows session variables
> * no changes in current functions support
> 
> Why new calling convention? I would to support byref variables and
> then I have to carry memory context info ... and maybe some others
> 
> Nice a weekend
> 
> Pavel Stehule
> 
> p.s.
> 
> Why procedures? New parts of ANSI SQL use it, and what is worse, they
> use methods:
> http://www.wiscorp.com/H2-2005-350-WG4-wlg005-Part-7-History-2nd-Edition-Text-for-Working-Draft.pdf
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
> 
>                 http://www.postgresql.org/about/donate

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

pgsql-hackers by date

Next:From: D'Arcy J.M. CainDate: 2007-11-05 06:28:07
Subject: Re: type money causes unrestorable dump
Previous:From: Tom LaneDate: 2007-11-05 02:13:52
Subject: Re: should I worry?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group