Re: proposal: schema PL session variables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: schema PL session variables
Date
Msg-id CAFj8pRC=k2OVC5EVfrC0seZ51Gre40cvo2GcDvY3pFRY9agc3Q@mail.gmail.com
Whole thread Raw
In response to Re: proposal: schema PL session variables  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: proposal: schema PL session variables
List pgsql-hackers


2016-02-09 23:31 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
On 2/8/16 10:02 AM, Pavel Stehule wrote:

    I think it would make sense to implement the interface in at least
    one of our other supported PLs. I'm not entirely clear how well this
    will match up with, say, plperl, but I'd be interested to see.


The minimalistic interface can be based on get/set functions. We can do
necessary transformations there.

get/set functions where?

I don't think that really makes sense. I would expect schema variables to be exposed to a function as variables or attributes, either in the global namespace for that PL, or as an attribute of some object (ie the plpy object in plpython).

I don't know a python, and I don't know what is possible there and what I know. Set/Get function I can implement in any PL other than PLpgSQL. You have to do conversion from Postgres type to PL types and I can do it in function.

 

I certainly wouldn't expect this patch to do that for all existing PLs, but I think it's important to do it for one PL besides plpgsql to make sure there's no gotchas.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: schema PL session variables
Next
From: Craig Ringer
Date:
Subject: Re: [COMMITTERS] pgsql: Code cleanup in the wake of recent LWLock refactoring.