Re: proposal: custom variables management

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

In response to

Responses

Browse pgsql-hackers by date

  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