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

Re: Proposal: real procedures again (8.4)

From: "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Gregory Stark" <stark(at)enterprisedb(dot)com>, 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-10-27 14:45:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
2007/10/27, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> "Pavel Stehule" <pavel(dot)stehule(at)gmail(dot)com> writes:
> > 2007/10/27, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> >> Most of that sounded to me like a proposal to re-invent ecpg.  If there
> >> were such a large demand for doing things that way, there would be many
> >> more users of ecpg than bare libpq.  AFAICT, though, *very* few people
> >> use ecpg.
> > With procedures we can be in conformance with ANSI standard and others
> > databases.
> [ shrug... ] If you want us to buy into supporting parts of the SQL spec
> other than Part 2, you need to make a case why --- the argument that
> "it's in the standard" cuts no ice at all with me for all that other
> stuff.  AFAICS the market demand for ecpg-style APIs is nil.

My goal is well support of SQL/PSM and well support of stored
procedures.   Conformance with ANSI is nice secondary effect.
Actually, current model of OUT params is dificult for learning, for
develop too (in C), and it's rare. I like it for functions, it is
really good idea, but isnot easy (and sometimes is limiting (in

I cannot do:
CREATE PROCEDURE foo(IN a int, OUT b varchar)
CREATE PROCEDURE foo(IN a int, OUT b integer)

CREATE FUNCTION foo(out a int, out b int)
  a := 10;
  b := 30;

CREATE FUN caller(out a int, out b int)
  SELECT INTO a,b foo()

Try to write these function in C.

With procedures it can be:


  return 0;  /* exit status */


   if (0 == DirectProcedureCall(DATUMBYREF(&a),


Pavel Stehule

In response to

pgsql-hackers by date

Next:From: Gregory StarkDate: 2007-10-27 15:00:26
Subject: Re: min/max planner optimization
Previous:From: Merlin MoncureDate: 2007-10-27 14:44:16
Subject: Re: Proposal: real procedures again (8.4)

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