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 &
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/
.
--
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
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
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 (
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
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_
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
{
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)---
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)---
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
40 matches
Mail list logo