Re: RFD: Don't force plpgsql IN parameters to constant

From: "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at>
To: "Tom Lane *EXTERN*" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Steve Prentice" <prentice(at)cisco(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFD: Don't force plpgsql IN parameters to constant
Date: 2009-07-30 07:13:17
Message-ID: D960CB61B694CF459DCFB4B0128514C203937E8B@exadv11.host.magwien.gv.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>>> Is there a reason we force plpgsql IN parameters to constant?
>
> Now having said all that, I'm not really in favor of Steve's
> proposal --- it seems like it mostly would be encouraging dubious
> programming practices. But it's hard to say that the arguments
> against are more than theoretical/aesthetic ones.
>
> Does anyone happen to know how it works in Oracle's PL/SQL?
> I think that following their lead is usually the argument-settler
> when it comes to plpgsql behavior.

Oracle 10.2.0.4:

CREATE PROCEDURE test2(a NUMBER) AUTHID CURRENT_USER AS
BEGIN
a := 2;
END;
/

PLS-00363: expression 'A' cannot be used as an assignment target

So it does not work in Oracle.

The proposed feature would have come handy for me once or twice,
but maybe that is more a sign of my sloppy coding habits than
anything else ...

Still, +1 from me for the proposal.

In my experience, restrictive languages have never kept people
from writing bad and confusing code.

What about introducing a keyword CONSTANT in the parameter list
to force the old behaviour?
(This would remove us further from Oracle though.)

Yours,
Laurenz Albe

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2009-07-30 07:44:28 Re: WIP: Deferrable unique constraints
Previous Message Pavel Stehule 2009-07-30 05:22:04 Re: Patch for 8.5, transformationHook