[PATCHES] Patch to correct 64-bit money type in 8.3devel

Attached is a patch for the 8.3devel 64-bit money type. Bug reported here: http://archives.postgresql.org/pgsql-bugs/2007-08/msg00137.php. Run the test program included in the bug report to see the issue. Then apply patch and run the test again. Andrew Chernow Index: src/backend/utils

[PATCHES] PGparam extension version 0.4

Version 0.4 of libpq param put and PGresult get functions. Added support for inet and cidr, couple bug fixes. If you compile the test file, make sure you link with the patched libpq.so. Andrew pg_param.tgz Description: application/compressed ---(end of broadcast)---

[PATCHES] PGparam extension version 0.4

Version 0.4 of libpq param put and PGresult get functions. Added support for inet and cidr, couple bug fixes. If you compile the test file, make sure you link with the patched libpq.so. Andrew pg_param.tgz Description: application/compressed ---(end of broadcast)---

[PATCHES] PQParam version 0.5

Here is the lastest pgparam patch. It is patched against a fresh checkout on 2007-12-05. This release adds support for printf-style param puts/execs. Instead of having to do a PQputX for each param, you can use a format string and put multiple params. PQputf(), PQparamExecf() and PQparamSen

Re: [PATCHES] PQParam version 0.5

Merlin Moncure wrote: On Dec 5, 2007 2:44 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote: Andrew Chernow escribió: Also changed PQputint8's prototype. Previously, it was using a void* as the value argument, due to a lack of a portable 64-bit type in libpq. We found an intersting

Re: [PATCHES] PQParam version 0.5

Tom Lane wrote: Andrew Chernow <[EMAIL PROTECTED]> writes: Here is the lastest pgparam patch. It is patched against a fresh checkout on 2007-12-05. What is this for? Why is it a good idea? It appears to be a fairly enormous increase in the size of libpq's API, and I really do

Re: [PATCHES] libpq type system 0.9a

The type names would be the same across the 15 servers but there is no guarentee the OIDs would be. Composites and arrays caused a few issues as well. We also tried to provide as much protection as possible ... in the spirit of the backend. -- Andrew Chernow eSilo, LLC every bit counts htt

Re: [PATCHES] libpq type system 0.9a

onally, I am not really in favor of this idea because it breaks apart code that is very related. Although, it is doable. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscrip

Re: [PATCHES] libpq type system 0.9a

Andrew Chernow wrote: Joe Conway wrote: Alvaro Herrera wrote: Merlin Moncure escribió: Yesterday, we notified -hackers of the latest version of the libpq type system. Just to be sure the right people are getting notified, we are posting the latest patch here as well. Would love to get some

[PATCHES] libpq patch for pqtypes hook api and PGresult creation

required changes to pqtypes; some work has already been done. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ Index: src/interfaces/libpq/exports.txt === RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq

[PATCHES] libpq Win32 Mutex performance patch

name, thus bound to process that created it, it still carries significant overhead compared to using win32 CRITICAL_SECTIONs. The attached patch replaces the win32 mutex calls with critical section calls. The change will not affect the behavior of the windows pthread_xxx functions. -- Andr

Re: [PATCHES] libpq Win32 Mutex performance patch

l is within a comment. I only put it there in case it is ever needeed. BTW, I just noticed the commented destroy call forgot to free(*mp) ... ooppssseee. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To

Re: [PATCHES] libpq Win32 Mutex performance patch

Tom Lane wrote: Andrew Chernow <[EMAIL PROTECTED]> writes: The attached patch replaces the win32 mutex calls with critical section calls. The change will not affect the behavior of the windows pthread_xxx functions. Why have you defined the lock/unlock functions as willing to fall t

Re: [PATCHES] libpq Win32 Mutex performance patch

Tom Lane wrote: Silently not locking is surely not very safe. Here is the dump code version of the patch. If anyone wants the return value idea, let me know. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ Index: src/port/pthread-win32.h

Re: [PATCHES] libpq Win32 Mutex performance patch

Andrew Chernow wrote: Tom Lane wrote: Silently not locking is surely not very safe. Here is the dump code version of the patch. If anyone wants the return value idea, let me know. A more graceful solution would

Re: [PATCHES] libpq Win32 Mutex performance patch

daveg wrote: On Fri, Apr 11, 2008 at 06:25:53PM -0400, Tom Lane wrote: Andrew Chernow <[EMAIL PROTECTED]> writes: A more graceful solution would be to print something to stderr and then exit. stderr doesn't exist, or point to a useful place, in many environments. And a forced e

Re: [PATCHES] libpq patch for pqtypes hook api and PGresult creation

Merlin Moncure wrote: On Fri, Apr 11, 2008 at 1:47 PM, Andrew Chernow <[EMAIL PROTECTED]> wrote: Here are the changes to libpq. It adds the ability to register an Object Hook and create a home-grown result. Patch adds 4 functions. We changed the name of PQresultSetFieldValue to PQse

Re: [PATCHES] libpq patch for pqtypes hook api and PGresult creation

hows these changes. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ Index: fe-connect.c === RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v retrieving revision 1.357 diff -C6 -r1.357 fe-connect.

Re: [PATCHES] libpq patch for pqtypes hook api and PGresult creation

ypes (put and get any type in binary including arrays & composites)? Playing with the idea: PQtypesLoad could take an argument specifying a libpqtypes version (for speaking to a particular backend). Could even add a PQtypesUnload so that you can unload+load a different version within the

[PATCHES] libpq object hooks patch

a and PQresultHookData can be removed. There functionality can be reproduced by an API user issuing PQobjectHooks or PQresultObjectHooks and manually looking for there hook (normaly to get at the hook->data). Basically, an API user would do themselves what PQhookData is doing. -- Andrew Chernow eSilo, L

Re: [PATCHES] libpq object hooks patch

Andrew Chernow wrote: Here is an updated version of the object hooks patch. It now supports a list of hooks for a PGconn, and PGresult. This had to re-introduce the concept of hook name. Being that there is now a list, you need a way to reference an item of that list. Also added

Re: [PATCHES] libpq object hooks

oesn't really change the concept at all ... just allows someone registering hooks with libpq to use something other than a string. The hookName string idea feels a little more natural and simple. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-patch

Re: [PATCHES] libpq object hooks

re NOT hook callbacks. The hook data is NOT isolated to callback functions. It is memory that is publically accessible, outside hook implementations. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To

Re: [PATCHES] libpq object hooks

patch), let us know. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ Index: exports.txt === RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/exports.txt,v retrieving revision 1.19 diff -C6 -r1.19 export

Re: [PATCHES] libpq object hooks

collision issues. // these function prototypes change as well void *PQhookData(PGconn *, const PGhookHandle); void *PQresultHookData(PGresult *, const PGhookHandle); We will send in an updated patch. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-patches

Re: [PATCHES] libpq object hooks

ch is constant and unique. app_func(PGresult *res) { PQresultHookData(res, ?handle?); } app_func is not aware of what PGconn generated the result so it has no idea what libpq returned handle to use. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-patches ma

Re: [PATCHES] libpq object hooks

Tom Lane wrote: Andrew Chernow <[EMAIL PROTECTED]> writes: There can be cases to use the same callbacks, although unlikely. To completely avoid collisions, the below would work: Still looks like overdesign to me. If we use the hook function address we solve the problem with no

Re: [PATCHES] libpq object hooks

Tom Lane wrote: Andrew Chernow <[EMAIL PROTECTED]> writes: Which callback do we use as the key? Currently, none are required (only the name was required). We have to choose one callback that must be provided. What? I thought what you wanted back was the void * pointer that ha

Re: [PATCHES] libpq object hooks

Tom Lane wrote: Andrew Chernow <[EMAIL PROTECTED]> writes: Which callback do we use as the key? Currently, none are required (only the name was required). We have to choose one callback that must be provided. What? I thought what you wanted back was the void * pointer that ha

Re: [PATCHES] libpq thread-locking

the above case, ENOMEM seems like a good fit. Also, maybe you should check the passed in mutex pointer. If its NULL, you could return EINVAL. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make

Re: [PATCHES] libpq object hooks

functions, being how our previous patches do not include a passthrough/user-pointer feature because libpqtypes didn't need it. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make chan

Re: [PATCHES] libpq object hooks

{ case PGEVT_RESULTCREATE: { void *data = makeresultdata() if(!data) return FALSE; ((PGEventResultCreate *)evtInfo)->stateData = data; break; } } return TRUE; } -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Andrew Ch

Re: [PATCHES] libpq object hooks

lls PQexec and an out-of-memory failure occurs. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches

Re: [PATCHES] libpq object hooks (libpq events)

the structures for event ids, like PGEVT_RESULTDESTROY has a corresponding PGEventResultDestroy structure. The PGEventProc function's 2nd argument is "void *info". The first argument is an event id which tells the proc implementor how to cast the void *. This replaced the initial va_

Re: [PATCHES] libpq object hooks (libpq events)

Merlin Moncure wrote: On Sat, May 17, 2008 at 8:28 AM, Andrew Chernow <[EMAIL PROTECTED]> wrote: Here is an updated patch for what was called object hooks. This is now called libpq events. If someone has a better name or hates ours, let us know. Let's decide where to go with thi

Re: [PATCHES] libpq object hooks (libpq events)

unc, data); The API user should have a valid instanceData whenever libpq returns a result, assuming they registered a callback that allocates instance data during a resultcreate event. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- Sent via pgsql-patches mailing list (

Re: [PATCHES] libpq object hooks (libpq events)

Tom Lane wrote: Andrew Chernow <[EMAIL PROTECTED]> writes: 4. add a setter for result instance data - There should also be a PQsetInstanceData(PGconn*, ...) - I see no need for a passThrough setter Check, though I assume we're not expecting PQsetInstanceData to propagate to

Re: [PATCHES] libpq object hooks (libpq events)

. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ libpq-events.tgz Description: application/compressed Index: src/interfaces/libpq/Makefile === RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/Makefile,v

[PATCHES] libpq events patch

ould be appreciated. Go here for libpqtypes using events. pgfoundry is still using the older object hooks version. http://libpqtypes.esilo.com/libpqtypes-events.tar.gz -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ Index: src/

Re: [PATCHES] libpq events patch

Andrew Chernow wrote: This is an updated version pf the libpqevents patch. See http://archives.postgresql.org/pgsql-hackers/2008-09/msg00153.php for details. The only change I didn't make yet is the event 'name'. I have put it in and taken it out twice now, so a firm &