Markus Schaaf wrote:
> src/interfaces/libpq/Makefile is missing a reference to libgssapi.
> The problem occurred while compiling 8.3.3 on NetBSD --with-gssapi,
> and is still present in HEAD. A patch is attached.
Applied and backpatched to 8.3.
Thanks!
//Magnus
--
Sent via pgsql-patches mailin
src/interfaces/libpq/Makefile is missing a reference to libgssapi.
The problem occurred while compiling 8.3.3 on NetBSD --with-gssapi,
and is still present in HEAD. A patch is attached.
Index: src/interfaces/libpq/Makefile
===
RCS file
David Rowley escribió:
> Alvaro Herrera wrote:
> >Oh, BTW: don't post to pgsql-patches. It's deprecated. Use
> > pgsql-hackers instead.
>
> I thought this too until I read
> http://wiki.postgresql.org/wiki/Submitting_a_Patch
>
> Which is correct?
I just updated that page and the developer's FA
Alvaro Herrera wrote:
>Oh, BTW: don't post to pgsql-patches. It's deprecated. Use
> pgsql-hackers instead.
I thought this too until I read
http://wiki.postgresql.org/wiki/Submitting_a_Patch
Which is correct?
David.
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To m
Andrew Chernow escribió:
> !
> printfPQExpBuffer(&conn->errorMessage,
> !
> libpq_gettext("PGEventProc \"%s\" failed during PGEVT_CONNRESET event\n"),
> !
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 'put it in there'
woul
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 'put it in the
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 'put it in there'
would be appreciated.
Go
Magnus Hagander wrote:
> Alvaro Herrera wrote:
> > 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.
> >
> > So is this a
On Mon, May 19, 2008 at 8:22 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Chernow <[EMAIL PROTECTED]> writes:
>> 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.
>
> This is starting to g
Attached is the latest patch. It has addressed the requested changes found
here: http://archives.postgresql.org/pgsql-patches/2008-05/msg00389.php
Its a tarball because there are two new files, libpq-events.c and
libpq-events.h. The patch is in the tarball as well as attached to the email.
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 previously cr
On Mon, May 19, 2008 at 10:37 PM, Tom Lane <[EMAIL PROTECTED]> 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'
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 previously created PGresult
Will make all of those changes. We appreciate the help.
1. remove global registration :(
2. New Name: PGCallback
3. use instanceData and passThrough names (passThrough with upper 'T')
3. separate getters for conn/result instanceData and passthrough
4. add a setter for result instance data
Andrew Chernow <[EMAIL PROTECTED]> writes:
> 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.
This is starting to get there, though I am still desperately unhappy
with the notion of "global"
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 this. We have
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 this. We have no objections to pus
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.
I am continuing to use the object hooks thread to avoid confusing anyone.
Terminology:
I got rid of calling it object events because it is poss
Tom Lane wrote:
ISTM the hook
ought to be able to request that libpq return an out-of-memory failure
for the query, just as would happen if the malloc failure had happened
directly to libpq.
I am working on this new patch and that is how I have been implementing it. If
the eventProc functi
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> On Fri, May 16, 2008 at 4:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
>> So you're imagining that on creation of a PGconn or PGresult, the
>> hook function would be allowed to create some storage and libpq would
>> then be responsible for tracking that
Tom Lane wrote:
Where
exactly does the hook hand off the storage pointer to libpq? What
are you going to do if the hook fails to create the storage
(ie, out of memory during PGresult creation)?
The current submitted patch has 3 of its function callbacks returning a
void*, initHookData after t
On Fri, May 16, 2008 at 4:23 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> Right. I actually overlooked the 'passthrough' in
>> PQregisterEventProc. It turns out that we are still not quite on the
>> same page and this needs to be clarified before we mo
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Right. I actually overlooked the 'passthrough' in
> PQregisterEventProc. It turns out that we are still not quite on the
> same page and this needs to be clarified before we move on. The
> passthrough cannot exist...
Yes, it *will* exist. You are
On Fri, May 16, 2008 at 3:49 PM, Merlin Moncure <[EMAIL PROTECTED]> wrote:
> On Fri, May 16, 2008 at 2:34 PM, Andrew Chernow <[EMAIL PROTECTED]> wrote:
>> Tom Lane wrote:
>>>
>>> typedef void (*PGeventProc) (PGeventId eventId, const void *eventInfo,
>>> void *passthrough
On Fri, May 16, 2008 at 2:34 PM, Andrew Chernow <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
>>
>> typedef void (*PGeventProc) (PGeventId eventId, const void *eventInfo,
>> void *passthrough);
>>
>> int PQregisterEventProc(PGconn *conn, PGeventProc proc, void
>> *passthr
Tom Lane wrote:
typedef void (*PGeventProc) (PGeventId eventId, const void *eventInfo,
void *passthrough);
int PQregisterEventProc(PGconn *conn, PGeventProc proc, void *passthrough);
The above prototypes will work and we will add our 'event instance
pointer' t
Bruce Momjian wrote:
> Magnus Hagander wrote:
> > Bruce Momjian wrote:
> > > Bruce Momjian wrote:
> > > > Magnus Hagander wrote:
> > > > > Attached patch adds some error checking to the thread locking
> > > > > stuff in libpq. Previously, if thread locking failed for some
> > > > > reason, we would
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
All of this is getting quite a long way from what was in the commitfest
queue. Do we still want to try to get this in this cycle, or should it
be marked returned to author for more work?
So far I think it still falls within
On Fri, May 16, 2008 at 11:21 AM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> All of this is getting quite a long way from what was in the commitfest
> queue. Do we still want to try to get this in this cycle, or should it be
> marked returned to author for more work?
That's your call...we can hav
Andrew Dunstan escribió:
> All of this is getting quite a long way from what was in the commitfest
> queue. Do we still want to try to get this in this cycle, or should it
> be marked returned to author for more work?
There are still patches open for which no discussion has even started,
so I
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> All of this is getting quite a long way from what was in the commitfest
> queue. Do we still want to try to get this in this cycle, or should it
> be marked returned to author for more work?
So far I think it still falls within the category of allowin
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> Switch, plus struct (basically a union) will do the trick nicely. Can
> it be a formal union, or is it better as a void*?
I don't think a union buys much notational convenience or safety here,
although admittedly it's a close question. In one case y
Merlin Moncure wrote:
Also, even if varargs are safe they'd be notationally unpleasant
in the extreme. varargs are just a PITA to work with --- you'd have
to do all the decoding in the first-level hook routine, even for
items you weren't going to use. With something like the above
all you
On Fri, May 16, 2008 at 10:59 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Merlin Moncure" <[EMAIL PROTECTED]> writes:
>>> typedef void *(*PGobjectEventProc)(PGobjectEventId evtId, ...);
>>> int PQregisterObjectEventProc(PGconn*, PGobjectEventProc);
>>> void *PQeventData(PGconn *, PGobjectEventProc);
Magnus Hagander wrote:
> Bruce Momjian wrote:
> > Bruce Momjian wrote:
> > > Magnus Hagander wrote:
> > > > Attached patch adds some error checking to the thread locking
> > > > stuff in libpq. Previously, if thread locking failed for some
> > > > reason, we would just fall through and do things wi
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> typedef void *(*PGobjectEventProc)(PGobjectEventId evtId, ...);
>> int PQregisterObjectEventProc(PGconn*, PGobjectEventProc);
>> void *PQeventData(PGconn *, PGobjectEventProc);
>> void *PQresultEventData(PGresult *, PGobjectEventProc);
> This provide
Andrew Chernow wrote:
> ! int
>pthread_mutex_init(pthread_mutex_t *mp, void *attr)
>{
> *mp = CreateMutex(0, 0, 0);
> + if (*mp == NULL)
> + return 1;
> + return 0;
>}
>
> Maybe it would be better to emulate what pthreads does. Instead of
> returing 1 to ind
! int
pthread_mutex_init(pthread_mutex_t *mp, void *attr)
{
*mp = CreateMutex(0, 0, 0);
+ if (*mp == NULL)
+ return 1;
+ return 0;
}
Maybe it would be better to emulate what pthreads does. Instead of
returing 1 to indicate an error, return an errno. In t
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Magnus Hagander wrote:
> > > Attached patch adds some error checking to the thread locking
> > > stuff in libpq. Previously, if thread locking failed for some
> > > reason, we would just fall through and do things without locking.
> > > This patch mak
On Thu, May 15, 2008 at 8:38 PM, Andrew Chernow <[EMAIL PROTECTED]> wrote:
> We need to add members to a conn and result, that's pretty much it. To do
> this, an api user can register callbacks to receive notifications about
> created/destroyed states of objects. PQhookData is just like PQerrorMe
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 had
been registe
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 had
been registe
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 had
been registered with a pa
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 extra notation
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 extra notation and no extra s
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> It might work to use the address of the hook callback function as
>> a key for retrieving the associated void * pointer. You'd need to
>> not register the same callback function more than once per object,
>> but from what I gather her
Andrew Dunstan wrote:
Tom Lane wrote:
It might work to use the address of the hook callback function as
a key for retrieving the associated void * pointer. You'd need to
not register the same callback function more than once per object,
but from what I gather here you don't need to.
Tom Lane wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
The problem is the functions PQhookData(conn, hookname) and
PQresultHookData(result, hookName). We need these to work in
functions that are not callbacks. If we eliminate hookname
completely, there is no way for libpq to know which p
Tom Lane wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
The problem is the functions PQhookData(conn, hookname) and
PQresultHookData(result, hookName). We need these to work in
functions that are not callbacks. If we eliminate hookname
completely, there is no way for libpq to know wh
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
> The problem is the functions PQhookData(conn, hookname) and
> PQresultHookData(result, hookName). We need these to work in
> functions that are not callbacks. If we eliminate hookname
> completely, there is no way for libpq to know which private stat
On Wed, May 14, 2008 at 10:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I'm wondering why the hooks need names at all. AFAICS all that
> libpq needs to know about a hook is a callback function address
> and a void * passthrough pointer.
I'm trying to make this work as you suggest.
It's pretty cl
On Wed, May 14, 2008 at 3:47 PM, daveg <[EMAIL PROTECTED]> wrote:
> On Wed, May 14, 2008 at 10:52:43AM -0400, Bruce Momjian wrote:
>>
>> One idea would be to add the libpq hooks but not document them. This
>> way, we can modify or remove the API as needed in the future. As
>> libpqtypes matures a
On Wed, May 14, 2008 at 10:52:43AM -0400, Bruce Momjian wrote:
>
> One idea would be to add the libpq hooks but not document them. This
> way, we can modify or remove the API as needed in the future. As
> libpqtypes matures and we are sure what the API should be, we can
> document it as stable a
Attached is an updated patch. The only change to this patch is that
hookNames are now compared with strcmp rather than strcasecmp. The
comparisons occur in fe-mics.c (bottom of file) during PQhookData and
PQresultHookData.
Not sure this needs clarification, but PQcopyResult, PQresultAlloc an
Merlin Moncure wrote:
On Wed, May 14, 2008 at 10:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
I'm wondering why the hooks need names at all. AFAICS all that
libpq needs to know about a hook is a callback function address
and a void * passthrough pointer.
For reference...here is what libpqtypes
On Wed, May 14, 2008 at 10:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> I'm wondering why the hooks need names at all. AFAICS all that
> libpq needs to know about a hook is a callback function address
> and a void * passthrough pointer.
For reference...here is what libpqtypes has to do to bind vi
I'm wondering why the hooks need names at all. AFAICS all that
libpq needs to know about a hook is a callback function address
and a void * passthrough pointer.
In question is:
+ void *
+ PQhookData(const PGconn *conn, const char *hookName)
Basically, libpqtypes has various functions that tak
On Wed, May 14, 2008 at 10:52 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> Merlin Moncure wrote:
>> Regarding the other comments:
>> *) API structure: Our major objective was to minimize exports to
>> libpq. I think both copyresult and setvalue have some possible
>> sideband usage (footguns or n
On Wed, May 14, 2008 at 10:44 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> No, they could revise their patch to be more stylistically in keeping
> with libpq. I haven't looked at the current version of the patch yet,
> but the early versions seemed quite overengineered to me, so your
> criticism didn
Merlin Moncure wrote:
> Regarding the other comments:
> *) API structure: Our major objective was to minimize exports to
> libpq. I think both copyresult and setvalue have some possible
> sideband usage (footguns or no). Additional functions could be
> speculated but are not required by libpqtype
On Tue, May 13, 2008 at 11:52 PM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> My personal opinion is still that I would like to see a more general
> usefulness for these functions before adding them to libpq. The
> complexity of the API just mirrors my gut feeling on this.
There has been a lot of
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> It should be noted that while this feels slightly foreign, it isn't
> hugely invasive, unlike the previous effort - it's only a few hundred
> lines of new code.
> If we reject this, presumably the authors will have no alternative than
> to offer libp
On Wed, May 14, 2008 at 8:18 AM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> Right, it was more the case insensitive part that bothered me.
Done. We in fact had realized this was a mistake anyways following
some profiling of the libpqtypes library. In some scenarios, this
function gets called a l
Alvaro Herrera wrote:
Andrew Dunstan escribió:
The thing that is a bit disturbing is that the whole style of this
scheme is very different from the fairly simple APIs that the rest of
libpq presents. It's going to make libpq look rather odd, I think. I
would have felt happier if the a
Andrew Dunstan escribió:
> The thing that is a bit disturbing is that the whole style of this
> scheme is very different from the fairly simple APIs that the rest of
> libpq presents. It's going to make libpq look rather odd, I think. I
> would have felt happier if the authors had been able
Andrew Dunstan wrote:
> The first thing it needs is lots and lots of documentation. I think it
> probably needs a Section in the libpq chapter all on its own, preferably
> with some examples. I think that lack alone is enough to keep it from
> being committed for now.
>
> Second, the hook names
Merlin Moncure wrote:
Attached is an updated version of 'libpq object hooks'. The primary
purpose for libpq object hooks is to support our libpqtypes system
(not attached), but could possibly some nice sideband features to
libpq. We are hoping to sneak this into the May commit fest.
I
Magnus Hagander wrote:
> Alvaro Herrera wrote:
> > 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.
> >
> > So is this a
Alvaro Herrera wrote:
> 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.
>
> So is this a patch we want applied?
Please see my other t
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.
So is this a patch we want applied?
--
Alvaro Herrerahttp://www
Bruce Momjian wrote:
> Magnus Hagander wrote:
> > Attached patch adds some error checking to the thread locking stuff in
> > libpq. Previously, if thread locking failed for some reason, we would
> > just fall through and do things without locking. This patch makes us
> > abort() instead. It's not t
Magnus Hagander wrote:
> Attached patch adds some error checking to the thread locking stuff in
> libpq. Previously, if thread locking failed for some reason, we would
> just fall through and do things without locking. This patch makes us
> abort() instead. It's not the greatest thing probably, but
Attached patch adds some error checking to the thread locking stuff in
libpq. Previously, if thread locking failed for some reason, we would
just fall through and do things without locking. This patch makes us
abort() instead. It's not the greatest thing probably, but our API
doesn't let us pass ba
Attached is an updated version of 'libpq object hooks'. The primary
purpose for libpq object hooks is to support our libpqtypes system
(not attached), but could possibly some nice sideband features to
libpq. We are hoping to sneak this into the May commit fest.
regards,
merlin
Index: exports.tx
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.
Here's a version of this patch that doesn't use malloc - instead, I had
to change the callers to
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 PQobjectHo
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 PQobjectHooks and PQresultObjectH
Merlin Moncure wrote:
> On Fri, Apr 11, 2008 at 2:49 PM, Magnus Hagander
> <[EMAIL PROTECTED]> wrote:
> > Andrew Chernow wrote:
> > > I noticed several months ago, and came across it again today,
> > > that libpq's pthread-win32.c implementation is using CreateMutex
> > > rather than CRITICAL_SE
Andrew Chernow wrote:
> 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/
Andrew Chernow wrote:
> Magnus Hagander wrote:
>
> >It changes the behavior when the pointer passed in is invalid from
> >crash to silent working, right?
>
> Correct, it a Habit. I sub-consciously write code that checks
> pointers. We can remove the pointer checks and let the thing dump
> core
Here is an updated version of the 'libpq-side' changes required to
implement the libpqtypes proposal. This fixes the complaints Tom had,
particularly the process lock on the various functions that kept
private state linked up with the PGconn. We did this in a slightly
different way than Tom propo
Kind of a long post, but if you take the time to read it we think it accurately
clarifies how we interrupt the current objections and how we see this working.
NOTE: any references to overhead are in regards to library size, not performance.
>would be to insert hooks at library
>_init() time, me
Andrew Chernow <[EMAIL PROTECTED]> writes:
> The requirements for the connCreate hook are that the PGconn is ready
> for use. I am currently hooking in connectDBStart, which is dead wrong.
I looked at the "object hooks" patch and it looked like a complete mess.
AFAICS the only way you could use
Should the hook only be called when the conn or result was
> successfull or should the hooks be called for failed
connections/commands as well?
ISTM that the hooks should be called on success and error (doesn't
include cases where a NULL conn or result is returned). I think this
makes th
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 PQsetvalue, w
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 exit() is no bett
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 exit() is no bett
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 exit() is no better than a crash for most purposes.
> I don't think libpq should core
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
through si
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
through silently if han
On Fri, Apr 11, 2008 at 2:49 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Andrew Chernow wrote:
> > I noticed several months ago, and came across it again today, that
> > libpq's pthread-win32.c implementation is using CreateMutex rather
> > than CRITICAL_SECTION. CreateMutex is like a sema
Magnus Hagander wrote:
>It changes the behavior when the pointer passed in is invalid from
>crash to silent working, right?
Correct, it a Habit. I sub-consciously write code that checks pointers.
We can remove the pointer checks and let the thing dump core if people
prefer.
Which brings u
Andrew Chernow wrote:
> I noticed several months ago, and came across it again today, that
> libpq's pthread-win32.c implementation is using CreateMutex rather
> than CRITICAL_SECTION. CreateMutex is like a semaphore in that it is
> designed to be accessible via name system-wide. Even when you
I noticed several months ago, and came across it again today, that
libpq's pthread-win32.c implementation is using CreateMutex rather than
CRITICAL_SECTION. CreateMutex is like a semaphore in that it is
designed to be accessible via name system-wide. Even when you don't
give it a name, thus b
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 PQsetvalue, which better
> comp
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 PQsetvalue, which better
compliments PQgetvalue. If this patch is acceptable, we will move on to
making the r
On Fri, Apr 4, 2008 at 6:56 PM, Alvaro Herrera
<[EMAIL PROTECTED]> 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.
1 - 100 of 155 matches
Mail list logo
