Re: proof concept - access to session variables on client side

2012/6/26 Magnus Hagander <magnus(at)hagander(dot)net>:
> On Tue, Jun 26, 2012 at 9:50 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> 2012/6/26 Magnus Hagander <magnus(at)hagander(dot)net>:
>>> On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>>>> Hello
>>>>
>>>> I worked on simple patch, that enable access from server side to
>>>> client side data. It add two new hooks to libpq - one for returning of
>>>> local context, second for setting of local context.
>>>>
>>>> A motivation is integration of possibilities of psql console together
>>>> with stronger language - plpgsql. Second target is enabling
>>>> possibility to save a result of some server side process in psql. It
>>>> improve vars feature in psql.
>>>>
>>>> pavel ~/src/postgresql/src $ cat test.sql
>>>> \echo value of external paremeter is :"myvar"
>>>>
>>>> do $$
>>>> begin
>>>>  -- we can take any session variable on client side
>>>>  -- it is safe against to SQL injection
>>>>  raise notice 'external parameter accessed from plpgsql is "%"',
>>>> hgetvar('myvar');
>>>>
>>>>  -- we can change this session variable and finish transaction
>>>>  perform hsetvar('myvar', 'Hello, World');
>>>> end;
>>>> $$ language plpgsql;
>>>>
>>>> \echo new value of session variable is :"myvar"
>>>>
>>>> cat test.sql | psql postgres -v myvar=Hello
>>>> value of external paremeter is "Hello"
>>>> NOTICE:  external parameter accessed from plpgsql is "Hello"
>>>> DO
>>>> new value of session variable is "Hello, World"
>>>>
>>>> This is just proof concept - there should be better integration with
>>>> pl languages, using cache for read on server side, ...
>>>>
>>>> Notices?
>>>
>>> Why not just use a custom GUC variable instead? E.g. you could have
>>> psql SET "psql.myvar='Hello, World'", and then you'd need no changes
>>> at all in the backend? Maybe have a "shorthand interface" for
>>> accessing GUCs in psql would help in making it easier, but do we
>>> really need a whole new variable concept?
>>
>> GUC variables doesn't help with access to psql's command line
>> parameters from DO PL code.
>
> But with a small change to psql they could, without the need for a
> whole new type of variable. For example, psql could set all those
> variable as "psql.<commandlinevarname>", which could then be accessed
> from the DO PL code just fine.

yes, it is possibility too. It has different issues - it can send
unwanted variables - maybe some compromise is optimum.

>
> --
>  Magnus Hagander
>  Me: http://www.hagander.net/
>  Work: http://www.redpill-linpro.com/