Re: Extended customizing, SQL functions, - Mailing list pgsql-hackers

From Shridhar Daithankar
Subject Re: Extended customizing, SQL functions,
Date
Msg-id 200405291922.49795.shridhar_daithankar@persistent.co.in
Whole thread Raw
In response to Re: Extended customizing, SQL functions,  (pgsql@mohawksoft.com)
List pgsql-hackers
On Saturday 29 May 2004 18:10, pgsql@mohawksoft.com wrote:
> Having internal PostgreSQL variables that are not present on disk, or
> maybe, variables that are mirrored on disk may be good.

Yes. I agree. I can see why you proposed no transactions few posts ago. Take 
an example of a count variable. It may not have transactions but it is 
expected not to be very accurate anyways.

If I can declare variables which can be changed/read in locked fashion and 
visible to all the backends would be a real great use. It shouldn't have 
transactions because it is not data but a state. It is in database so that 
other connections and stored procedures could see it.

Coupled with the fact that postgresql has custom data types, there is no end 
how this could be put to use. Lot more things that sit in application layer 
will be inside postgresql, I can image.

> The whole reason why I made this post was to see if other people have had
> similar issues and looked for a similar solution, and to think about if
> there is a solution that fits within PostgreSQL and how it would work.

AFAIK, there is no way of doing it in postgresql. But I would love to see it 
happen. (I wish I could work on it...:-( )
Shridhar


pgsql-hackers by date:

Previous
From: Oliver Elphick
Date:
Subject: Re: CVS tip problems
Next
From: Christopher Browne
Date:
Subject: Re: Win32, PITR, nested transactions, tablespaces