Re: [PATCHES] Partial match in GIN (next vesrion)

2008-05-16 Thread Teodor Sigaev
There seems to be something broken here: it's acting like prefix search is on all the time, eg I'm in sackcloth and ashes... Fixed and extended regression tests. http://www.sigaev.ru/misc/tsearch_prefix-0.9.gz -- Teodor Sigaev E-mail: [EMAIL PROTECTED]

Re: [PATCHES] Patch to change psql default banner v6

2008-05-16 Thread David Fetter
On Fri, May 16, 2008 at 01:22:55AM -0400, Tom Lane wrote: David Fetter [EMAIL PROTECTED] writes: I believe there's a bug in this patch, namely that the warnings when there's a server-client mismatch only appear at startup time. Please do not blame this patch for a problem that has been

Re: [PATCHES] Patch to change psql default banner v6

2008-05-16 Thread Tom Lane
David Fetter [EMAIL PROTECTED] writes: I believe there's a bug in this patch, namely that the warnings when there's a server-client mismatch only appear at startup time. Please do not blame this patch for a problem that has been there all along. I don't say that the point doesn't need

Re: [PATCHES] Patch to change psql default banner v6

2008-05-16 Thread David Fetter
On Thu, May 15, 2008 at 03:21:37PM -0400, Bruce Momjian wrote: Alvaro Herrera wrote: I'm OK with thisG but please move the printSSLInfo() call just before echoing the help line. Oh, good catch, moved. I also moved the Win32 code page message up too. Patch attached. I hacked up an

Re: [PATCHES] libpq object hooks

2008-05-16 Thread Merlin Moncure
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

Re: [PATCHES] libpq thread-locking

2008-05-16 Thread Magnus Hagander
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()

Re: [PATCHES] libpq thread-locking

2008-05-16 Thread Andrew Chernow
! 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

Re: [PATCHES] libpq thread-locking

2008-05-16 Thread Magnus Hagander
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

Re: [PATCHES] libpq object hooks

2008-05-16 Thread Tom Lane
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

Re: [PATCHES] libpq thread-locking

2008-05-16 Thread Bruce Momjian
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.

Re: [PATCHES] libpq object hooks

2008-05-16 Thread Merlin Moncure
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

Re: [PATCHES] libpq object hooks

2008-05-16 Thread Tom Lane
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

Re: [PATCHES] libpq object hooks

2008-05-16 Thread Alvaro Herrera
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

Re: [PATCHES] libpq object hooks

2008-05-16 Thread Merlin Moncure
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

Re: [PATCHES] libpq object hooks

2008-05-16 Thread Andrew Dunstan
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

Re: [PATCHES] libpq object hooks

2008-05-16 Thread Tom Lane
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

Re: [PATCHES] libpq object hooks

2008-05-16 Thread Andrew Dunstan
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

Re: [PATCHES] Fix for psql pager computations

2008-05-16 Thread Bruce Momjian
Bruce Momjian wrote: The attached patch causes psql to use the pager if newlines or 'format=wrapped' has caused a single row to span more than one line and the output is then too long for the screen. It also uses the pager if psql thinks the data will wrap off the edge of the screen. The

Re: [PATCHES] Patch to change psql default banner v6

2008-05-16 Thread Bruce Momjian
Bruce Momjian wrote: OK, here is the mega-print: $ psql test psql (8.4devel, server 8.4devel) WARNING: psql version 8.4, server version 8.4. Some psql features might not work. WARNING: Console code page (44) differs from Windows code page (55)

Re: [PATCHES] Partial match in GIN (next vesrion)

2008-05-16 Thread Tom Lane
Teodor Sigaev [EMAIL PROTECTED] writes: http://www.sigaev.ru/misc/partial_match_gin-0.10.gz http://www.sigaev.ru/misc/tsearch_prefix-0.9.gz http://www.sigaev.ru/misc/wildspeed-0.12.tgz I've applied the first two of these with minor editorialization (mostly fixing documentation). However, I'm

Re: [PATCHES] libpq thread-locking

2008-05-16 Thread Magnus Hagander
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

Re: [PATCHES] libpq object hooks

2008-05-16 Thread Andrew Chernow
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'

Re: [PATCHES] Partial match in GIN (next vesrion)

2008-05-16 Thread Oleg Bartunov
Wildspeed was designed as an example application of the GIN's partial match and as a useful extension for *short* strings. It's also good standalone demonstration of GIN API. We tried to stay away from full text search, parser, word delimiters and etc. From that point of view it might be

Re: [PATCHES] libpq object hooks

2008-05-16 Thread Merlin Moncure
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

Re: [PATCHES] libpq object hooks

2008-05-16 Thread Merlin Moncure
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

Re: [PATCHES] libpq object hooks

2008-05-16 Thread Tom Lane
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

Re: [PATCHES] libpq object hooks

2008-05-16 Thread Merlin Moncure
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

Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

2008-05-16 Thread Tom Lane
Zoltan Boszormenyi [EMAIL PROTECTED] writes: Attached patch implements the extension found in the current SQL200n draft, implementing stored start value and supporting ALTER SEQUENCE seq RESTART; Updated patch implements TRUNCATE ... RESTART IDENTITY which restarts all owned sequences for the

Re: [PATCHES] libpq object hooks

2008-05-16 Thread Andrew Chernow
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

Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

2008-05-16 Thread Neil Conway
On Fri, 2008-05-16 at 19:41 -0400, Tom Lane wrote: Applied with corrections. Most notably, since ALTER SEQUENCE RESTART is nontransactional like most other ALTER SEQUENCE operations, I rearranged things to try to ensure that foreseeable failures like deadlock and lack of permissions would be

Re: [PATCHES] [HACKERS] TRUNCATE TABLE with IDENTITY

2008-05-16 Thread Tom Lane
Neil Conway [EMAIL PROTECTED] writes: Ugh. The fact that the RESTART IDENTITY part of TRUNCATE is non-transactional is a pretty unsightly wort. Actually, I agree. Shall we just revert that feature? The ALTER SEQUENCE part of this patch is clean and useful, but I'm less than enamored of the

Re: [PATCHES] libpq object hooks

2008-05-16 Thread Tom Lane
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?

Re: [PATCHES] libpq object hooks

2008-05-16 Thread Andrew Chernow
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