Skip site navigation (1) Skip section navigation (2)

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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: David Fetter <david(at)fetter(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: proof concept - access to session variables on client side
Date: 2012-06-26 18:47:55
Message-ID: CAFj8pRBeu5mQh0OZzy1erQV3_=P5M7_WWULcOt=crXjfC5-Mtg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2012/6/26 David Fetter <david(at)fetter(dot)org>:
> On Tue, Jun 26, 2012 at 10:12:52AM +0200, Pavel Stehule wrote:
>> 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 -
>
> Could you expand on this just a bit?  Are you picturing something an
> attacker could somehow use, or...?

it is not security issue - just I dislike sending complete stack, when
just only one variable should be used.

Regards

Pavel

>
> Cheers,
> David.
> --
> David Fetter <david(at)fetter(dot)org> http://fetter.org/
> Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
> Skype: davidfetter      XMPP: david(dot)fetter(at)gmail(dot)com
> iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
>
> Remember to vote!
> Consider donating to Postgres: http://www.postgresql.org/about/donate
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-06-26 18:50:51
Subject: Re: why roll-your-own s_lock? / improving scalability
Previous:From: Merlin MoncureDate: 2012-06-26 18:46:06
Subject: Re: why roll-your-own s_lock? / improving scalability

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group