From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)hotmail(dot)com> |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: proposal: custom variables management |
Date: | 2007-03-05 22:32:18 |
Message-ID: | 45EC9A72.7090408@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Pavel Stehule wrote:
>>
>> ISTM you are trying to do too much. We need to get the base
>> functionality, as described by Tom in the thread I referred you to,
>> working first. Extra stuff could be added later if necessary.
>>
>> cheers
>>
>
> I don't wont to build cathedral. Now is time for discussion, no? I am
> collect any arguments. With "enhanced" custom variables we can fill
> modules hole in plpgsql or any pl. With it security definer's
> procedures in any languages can safety share values. I worked on large
> wramework designed for plpgsql, and we had to store some temp values
> in temporary tables. Safe custom variables can be solution. It's only
> idea, nothing more.
>
Right now the main uses I have seen referred to only involve doing
custom variables right, rather than exposing any extra API. For example,
in plperl we might have a variable that contains a list of modules
considered safe to load, and preload them. We would obviously want that
to be PGC_SUSET, at least. But this only needs DefineCustomFooVariable()
to work right. Nothing would need to be exposed to plperl itself, and no
extra functionality is needed for at the C level. If you think there's a
case for some extra functionality to be exposed, maybe you could provide
some more examples / use cases.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2007-03-05 22:43:02 | Re: Bug: Buffer cache is not scan resistant |
Previous Message | Tom Lane | 2007-03-05 22:19:58 | Re: Bug: Buffer cache is not scan resistant |