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

From Andrew Dunstan
Subject Re: proposal: custom variables management
Date
Msg-id 45EC9A72.7090408@dunslane.net
Whole thread Raw
In response to Re: proposal: custom variables management  ("Pavel Stehule" <pavel.stehule@hotmail.com>)
Responses Re: proposal: custom variables management  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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


pgsql-hackers by date:

Previous
From: "Mike Rylander"
Date:
Subject: xml2 contrib patch supporting default XML namespaces
Next
From: Jeff Davis
Date:
Subject: Re: Bug: Buffer cache is not scan resistant