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

Re: schema level variables and deferrable unique constraints

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Andre <andre(at)abs(dot)ee>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Paramveer(dot)Singh(at)trilogy(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: schema level variables and deferrable unique constraints
Date: 2004-09-20 18:11:35
Message-ID: 414F1D57.50605@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

Joe Conway wrote:

> Andre wrote:
>
>> Package variables are not transactional, additionaly they are
>> session based - each session has it's own variables(values).
>> You can assign initial(defult) values in package spec.
>> Using table for them would also imply several columns
>> for each datatype or several tables for them.
>
>
> I did a crude implementation of session variables for my OSCON 
> tutorial which can be found here:
>   http://www.joeconway.com/tut_oscon_2004.pdf
> See the slides with myfunc_setvar(), myfunc_getvar(), and myfunc_rmvar().
>
> I have a slightly improved version that I'm using on a production 
> system with good results. You can get the tarball here:
>
> http://www.joeconway.com/pgsession.tar.gz
>
> There was another implementation of session variables based on shared 
> memory floating around the lists somewhere. You might try searching 
> the archives for that also.
>
>

In 8.0 plperl has %_SHARED, which is essentially a stash for 
session-persistent data of arbitrary complexity. It's one of the new 
features. Writing get/set functions for them would be entirely trivial. 
Seeding them with inital defaults would involve an explicit function 
call at session startup - we don't have that automated for plperl yet.

cheers

andrew

In response to

pgsql-hackers by date

Next:From: Gaetano MendolaDate: 2004-09-20 18:15:03
Subject: RSS
Previous:From: Joe ConwayDate: 2004-09-20 17:55:56
Subject: Re: schema level variables and deferrable unique constraints

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