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?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
