Re: Extended customizing, SQL functions,

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