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
* 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
* 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)
In response to
pgsql-hackers by date
|Next:||From: Thomas Hallgren||Date: 2004-05-29 15:38:16|
|Subject: Re: dynamic_library_path on Win32 |
|Previous:||From: Stephan Szabo||Date: 2004-05-29 15:25:27|
|Subject: Re: Nested xacts: looking for testers and review|