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

From Shridhar Daithankar
Subject Re: Extended customizing, SQL functions,
Date
Msg-id 200405292057.54156.shridhar@frodo.hserus.net
Whole thread Raw
In response to Re: Extended customizing, SQL functions,  (pgsql@mohawksoft.com)
List pgsql-hackers
On Saturday 29 May 2004 20:48, pgsql@mohawksoft.com wrote:
> 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?

This is effectively a stored procedure isn't it? I have few points on this 
approach

* Every backend has to load it or somebody has to call it as a coding 
standard. Even if postmaster preloads it I doubt it will invoke it but 
correct me if I am wrong.

* This approach puts the code that you would have put in application 
otherwise. I mean it makes sense but just restating for my clarification

* How do you expose pg datatypes to such a system? Or keep it limited to basic 
variables?

* How do you access it from other stored procedures and SQL commands? If you 
do it in C, may be C routines can use it but what about other procedural 
language? I think you would need SPI co-operation.

All in all looks good starting point to me. But it won't be postgresql enough 
but a custom C function. ( That is useful as well though)
Shridhar


pgsql-hackers by date:

Previous
From: Stephan Szabo
Date:
Subject: Re: Nested xacts: looking for testers and review
Next
From: Tom Lane
Date:
Subject: Re: dynamic_library_path on Win32