2012/6/26 David Fetter <da...@fetter.org>:
> On Tue, Jun 26, 2012 at 10:12:52AM +0200, Pavel Stehule wrote:
>> 2012/6/26 Magnus Hagander <mag...@hagander.net>:
>> > On Tue, Jun 26, 2012 at 9:50 AM, Pavel Stehule <pavel.steh...@gmail.com>
>> > wrote:
>> >> 2012/6/26 Magnus Hagander <mag...@hagander.net>:
>> >>> On Tue, Jun 26, 2012 at 7:06 AM, Pavel Stehule <pavel.steh...@gmail.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 <da...@fetter.org> http://fetter.org/
> Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
> Skype: davidfetter XMPP: david.fet...@gmail.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
