Re: pulling libpqtypes from queue
От | Andrew Chernow |
---|---|
Тема | Re: pulling libpqtypes from queue |
Дата | |
Msg-id | 4804CDA4.5090702@esilo.com обсуждение исходный текст |
Ответ на | Re: pulling libpqtypes from queue (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: pulling libpqtypes from queue
|
Список | pgsql-hackers |
Martijn van Oosterhout wrote: > On Tue, Apr 15, 2008 at 11:24:43AM -0400, Andrew Chernow wrote: >>> libpqtypes had a superclassing concept (not much discussed on the >>> lists) where you could introduce new type handlers that wrapped >>> existing ones and was desgined exactly for things like this. keep an >>> eye on our upcoming pgfoundry project. >> /* register a new type named secure_text. Make it a >> * sub-class of bytea. Subclass means you can extend >> * the behavior of another type. >> */ > > All I can say is, way cool. Pity you couldn't get the necessary support > but if you can put it up in a way so it can be easily packaged by > distributors that'd be cool. I can think of some projects that could > really benefit from a feature like this. > > Have a nice day, We are working on a version to put on pgfoundry. This version will add stub functions to libpq and have the meat of the pqtypes in separate shared library: loadable via PQtypesLoad(){ dlopen("libpqtypes.so"); dlsym("pqt_paramExec"); dlsym("pqt_paramCreate"); // etc... } Maybe we'll get enough support in the future to get our stubs into core. Until then, you'll have to patch libpq. We planto provide binary patches for the major platforms. You won't have to patch the guts of pqtypes though because that is dynamically loaded behind PQtypesLoad ... you just need libpqtypes.[so|dll] in your libpath. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/
В списке pgsql-hackers по дате отправления: