Re: Controlling changes in plpgsql variable resolution

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Controlling changes in plpgsql variable resolution
Date: 2009-10-19 17:37:25
Message-ID: b42b73150910191037p4133a9a7r4d06fbf81a5d9aac@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 19, 2009 at 12:49 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "David E. Wheeler" <david(at)kineticode(dot)com> writes:
>> I'd sure love $, as it's like shell, Perl, and other stuff.
>
> This discussion has gotten utterly off track.  The problem I am trying
> to solve is a non-Oracle-compatible behavior in plpgsql.  I have got
> substantially less than zero interest in proposals that "solve" the
> problem by introducing notations that don't even pretend to be
> compatible.

Personally, I'd vote against a GUC option. I just plain don't like the
idea that a function could do different things depending on server
configuration. TBH, I'm not very happy with #option either. That
said, I agree that Oracle method is far better.

Maybe invent a new language handler? plpgsql2 or shorten to pgsql?
Now you can mess around all you want (and maybe fix some other
compatibility warts at the same time).

merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-10-19 17:46:47 Re: Controlling changes in plpgsql variable resolution
Previous Message Pavel Stehule 2009-10-19 17:17:52 Re: Controlling changes in plpgsql variable resolution