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
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 mailing
Andrew Chernow escribió:
!
printfPQExpBuffer(conn-errorMessage,
!
libpq_gettext(PGEventProc \%s\ failed during PGEVT_CONNRESET event\n),
!
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
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
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'
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'
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 patch we want applied?
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 get there,
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
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:
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 PGresults?
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're not
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
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.
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 pushing
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
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
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
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 makes us abort()
! 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
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 indicate an
Merlin Moncure [EMAIL PROTECTED] writes:
typedef void *(*PGobjectEventProc)(PGobjectEventId evtId, ...);
int PQregisterObjectEventProc(PGconn*, PGobjectEventProc);
void *PQeventData(PGconn *, PGobjectEventProc);
void *PQresultEventData(PGresult *, PGobjectEventProc);
This provides what we
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 without locking.
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);
void
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 allowing
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
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 have a
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
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 you're
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
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 just fall through and
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'
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
*passthrough);
The
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);
int
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 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 move on. The
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
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 storage?
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
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 clear
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 state we
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
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
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 here you
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
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:
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:
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
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
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
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
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 libpqtypes
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
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't
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 no).
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
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 via
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
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
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 and
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 and we are
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 Herrera
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 thread about libpq
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 patch we want applied?
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 are
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 to
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
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 the
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
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:
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 it a
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 if
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/unlock functions
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_SECTION.
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
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
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
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,
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,
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
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 it
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
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
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
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
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 up
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 semaphore in
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 handed
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
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
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
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 dump
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 better than a
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
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. Would
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
feedback on this.
I had a look at this patch some days ago,
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
feedback on this.
I had a look at this
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
feedback on this.
I
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
1 - 100 of 140 matches
Mail list logo
