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
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
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
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
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
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
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
usefu
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
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,
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)
>
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.
>
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
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 hac
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 inves
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
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]
33 matches
Mail list logo
