Re: proposal: custom variables management - Mailing list pgsql-hackers

From Tom Lane
Subject Re: proposal: custom variables management
Date
Msg-id 26386.1173154539@sss.pgh.pa.us
Whole thread Raw
In response to Re: proposal: custom variables management  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> ... So it's really a pretty poor fit.  If we want to support
>> general-purpose intrasession variables, I think something other than GUC
>> ought to be providing 'em.  (And, of course, it seems likely that you
>> could provide such functionality with a few functions in
>> your-favorite-PL, without any core changes at all.)

> I think I agree with you :-)

> But then every PL needs to invent it's own variable persistence

Why?  You do it once, you can call it from SQL or any PL.  Doing it in a
PL would constrain you to using a function-like syntax whereas a core
feature would have more flexibility of syntax, but I don't see that as a
big advantage --- looking at GUC's history, we've added function-style
APIs (current_setting() etc) when we already had specialized syntax.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bug: Buffer cache is not scan resistant
Next
From: "Luke Lonergan"
Date:
Subject: Re: Bug: Buffer cache is not scan resistant