Looking at this now. Wouldn't it be a good idea for comparePartial
to get the strategy number of the operator? As you have it set up,
I doubt that an opclass can support more than one partial-match
operator.
It might be useful, although I don't see any usage of that right now. I'll add
this o
On Tue, May 13, 2008 at 10:47:40AM -0400, Alvaro Herrera wrote:
> Tom Lane escribió:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > David Fetter escribi?:
> > >> Thanks for the heads-up :)
> > >>
> > >> Second patch attached, this time with some docs.
> >
> > > Added to July commitfest.
> >
On Tue, May 13, 2008 at 08:14:51AM -0700, David Fetter wrote:
> On Tue, May 13, 2008 at 10:47:40AM -0400, Alvaro Herrera wrote:
> > Tom Lane escribió:
> > > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > > David Fetter escribi?:
> > > >> Thanks for the heads-up :)
> > > >>
> > > >> Second patch
David Fetter <[EMAIL PROTECTED]> writes:
>>> Surely this is merely proof of concept and not a complete patch.
>>
>> Next patch attached :)
Uh, my point was that the agreement was to do this to *all* of psql's
toggling backslash commands, not only \timing.
regards, tom lan
Patch applied. Thanks.
---
Fujii Masao wrote:
> This is the patch replace offnum++ by OffsetNumberNext.
>
> According to off.h, OffsetNumberNext is the macro prepared to
> disambiguate the different manipulations on Offse
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
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
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 Tue, May 13, 2008 at 11:36:57AM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> >>> Surely this is merely proof of concept and not a complete patch.
> >>
> >> Next patch attached :)
>
> Uh, my point was that the agreement was to do this to *all* of
> psql's toggling backsla
On Tue, May 13, 2008 at 01:53:33PM -0700, David Fetter wrote:
> On Tue, May 13, 2008 at 11:36:57AM -0400, Tom Lane wrote:
> > David Fetter <[EMAIL PROTECTED]> writes:
> > >>> Surely this is merely proof of concept and not a complete patch.
> > >>
> > >> Next patch attached :)
> >
> > Uh, my point
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> I am sending enhanced version of original patch.
Applied with syntax revisions as per pghackers discussion.
I made a couple of other changes too: I took out the restriction against
throwing codes that are category codes, and instead just documented th
2008/5/14 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> I am sending enhanced version of original patch.
>
> Applied with syntax revisions as per pghackers discussion.
thank you
>
> I made a couple of other changes too: I took out the restriction against
> throwing
David Fetter <[EMAIL PROTECTED]> writes:
> On Tue, May 13, 2008 at 11:36:57AM -0400, Tom Lane wrote:
>>> Uh, my point was that the agreement was to do this to *all* of
>>> psql's toggling backslash commands, not only \timing.
>>
>> Done :)
Hmm, I thought we had a lot more than three that were lik
Martin Pihlak <[EMAIL PROTECTED]> writes:
> Now I just realized that the current patch doesn't handle this quite
> correctly. Modified patch attached.
I'm starting to look through this now, and I notice that the various
code paths in execQual.c are not too consistent about whether it counts
as a c
Tom Lane escribió:
> Actually, \a and \H are fairly bogus anyway, because they are "toggling"
> a setting that has more than two values. I wonder whether defining the
> argument as a boolean is really very sane. Perhaps it would be better to
> take the argument if given as just a regular format
I wrote:
> I'm starting to look through this now,
I found another fairly big problem, which is that this stuff isn't even
going to begin to compile on Windows.
What I think we should do about that is forget tracking getrusage()'s
user/system/real time and just track elapsed time. We have the
tec
On Sun, 11 May 2008, Hans-Juergen Schoenig wrote:
we also made some simple autoconf hack to check for broken posix_fadvise.
Because of how you did that, your patch is extremely difficult to even
test. You really should at least scan the output from diff you're about
to send before submittin
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
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
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
Tom Lane wrote:
I wrote:
I'm starting to look through this now,
I found another fairly big problem, which is that this stuff isn't even
going to begin to compile on Windows.
Where exactly is taht problem? In getrusage()? We have a getrusage() in
src/port that works fine on Windows, no?
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I found another fairly big problem, which is that this stuff isn't even
>> going to begin to compile on Windows.
> Where exactly is taht problem? In getrusage()? We have a getrusage() in
> src/port that works fine on Windows, no?
H
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I found another fairly big problem, which is that this stuff isn't even
going to begin to compile on Windows.
Where exactly is taht problem? In getrusage()? We have a getrusage() in
src/port that works fine on Window
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Huh ... I'd forgotten about that ... although it seems to work only for
>> rather small values of "work", since the WIN32 code path isn't paying
>> attention to the "who" argument.
> True, but it works for this case :-)
Shouldn't we
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Huh ... I'd forgotten about that ... although it seems to work only for
rather small values of "work", since the WIN32 code path isn't paying
attention to the "who" argument.
True, but it works for this case :-)
Sh
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Shouldn't we at least make it fail with EINVAL if "who" doesn't match
>> whichever semantics this code is able to implement?
> Yeah, we only ever call it asking for our own process, but I guess we
> might at some point in the future
26 matches
Mail list logo
