Re: proposal: schema PL session variables

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Oleg Bartunov <obartunov(at)gmail(dot)com>
Subject: Re: proposal: schema PL session variables
Date: 2016-02-10 19:06:09
Message-ID: 56BB8A21.8060701@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/10/16 11:33 AM, Pavel Stehule wrote:
>
> 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.

Requiring PLs to go through the native SPI to get to schema variables is
just plain ugly and inefficient. Why wouldn't they be exposed natively?

Not designing these things through is how we ended up with the mess that
is composite types and arrays in plpython and pltcl. I'm not saying any
PLs besides plpgsql need to support this natively out of the box, but we
better have an idea of how they would support it (and it'd be a good
idea if at least one other PL did support it).
--
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2016-02-10 19:10:17 Re: proposal: schema PL session variables
Previous Message Pavel Stehule 2016-02-10 19:04:39 Re: proposal: schema PL session variables