Re: Out parameters handling

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Asko Oja" <ascoja(at)gmail(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Out parameters handling
Date: 2009-03-06 22:13:43
Message-ID: 49B14BB6.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>> "Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com> wrote:
> On Fri, Mar 6, 2009 at 4:29 PM, Asko Oja <ascoja(at)gmail(dot)com> wrote:
>> It really sucks what kind of mistakes you can pass to production
>> unknowingly. I would much prefer a way to prevent such nonsense.
>> Here was the case where out parameters were with same names with
>> select into field names resulting in null outcome. Just yesterday
>> we had similar case with update statement.
>
> Well, it's a problem with the language not parsing things correctly
> and doing, in many cases, brain-dead replacements. I don't know of
> any developer using OUT parameters that doesn't run into this
> problem at one time or another :(

I find the PostgreSQL implementation of OUT parameters, well,
surprising. I've used databases where stored procedures can have a
RETURN value, OUT parameters, and result streams as three discreet
things which can't be mistaken for one another -- which seems more
sensible. Is this issue in PostgreSQL a spin-off of not having stored
procedures, and trying to shoehorn SP behavior into functions?

I suspect that a really good fix would require a new version of the
PostgreSQL protocol.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2009-03-06 22:57:43 Re: Out parameters handling
Previous Message Magnus Hagander 2009-03-06 22:03:35 Re: poor wording on SSPI error message