Re: Extended customizing, SQL functions,

> On Saturday 29 May 2004 18:10, pgsql(at)mohawksoft(dot)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...:-( )
>

I was thinking that it could be done as a contrib/pgfoundary function. I
think, but am not sure, that a function can be pre-loaded into the main
postgresql backend (postmaster) prior to starting other connections. I'll
have to check that out, but I think it is true, if it isn't it should be
possible to modify postmaster to do so.

The function module, when loaded, looks for its shared memory block, if
none is found, then it procededs to create the block, mutex, etc.

Then, it is a fairly simple task of managing a name/value table protected
by mutex.

Make sense?