| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Pavel Stehule <pavel(dot)stehule(at)hotmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: proposal: custom variables management |
| Date: | 2007-03-06 04:15:39 |
| Message-ID: | 26386.1173154539@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Luke Lonergan | 2007-03-06 04:23:04 | Re: Bug: Buffer cache is not scan resistant |
| Previous Message | Jim Nasby | 2007-03-06 04:11:14 | Re: Bug: Buffer cache is not scan resistant |