-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 11, 2008 at 1:40 PM, Tom Lane wrote:
> "Brendan Jurd" writes:
>
> > Not really. I'm claiming that, to the submitter, a response that
> > hasn't happened yet and a response that is never coming look pretty
> > much identical.
>
> I und
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> Not really. I'm claiming that, to the submitter, a response that
> hasn't happened yet and a response that is never coming look pretty
> much identical.
I understand, but that seems a bit offtopic seeing that this whole
thread is about how to guarantee
On Fri, Apr 11, 2008 at 1:01 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > I just wanted to correct the apparent impression that "patches don't
> > get ignored here". Patches get ignored. The difference between us
> > and Apache is we pretend it doesn
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > That is a nice list, but are these used for bug tracking or patch
> > tracking?
>
> In my experience, these two concepts become mostly the same. Just one is
> classified "normal" or "critical" and the the other is tagged "wishlist"
> and "patch
* Joshua D. Drake <[EMAIL PROTECTED]> [080410 23:20]:
> On Thu, 10 Apr 2008 22:47:34 -0400
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > > If you have something to add, please do so at some time, but if you
> > > are not interested in using a tracker
Brendan Jurd wrote:
> I'm not saying Bruce is doing a bad job, far from it. I'm saying the
> job is impossible.
>
> I just wanted to correct the apparent impression that "patches don't
> get ignored here". Patches get ignored. The difference between us
> and Apache is we pretend it doesn't happ
On Thu, 10 Apr 2008 22:47:34 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > If you have something to add, please do so at some time, but if you
> > are not interested in using a tracker anyway, just don't use it and
> > ignore this thread.
>
> Hmm, we
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> I just wanted to correct the apparent impression that "patches don't
> get ignored here". Patches get ignored. The difference between us
> and Apache is we pretend it doesn't happen and don't suggest to
> submitters what action to take when it does. W
On Fri, Apr 11, 2008 at 1:06 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> I assume you also read this Apache heading:
>
> What if my patch gets ignored?
>
> Because Apache has only a small number of volunteer developers,
> and these developers are often very busy, it is p
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> If you have something to add, please do so at some time, but if you are not
> interested in using a tracker anyway, just don't use it and ignore this
> thread.
Hmm, well, I can hardly see how anyone could object to a tracker that
they didn't have to
Gregory Stark wrote:
> This thread has already consumed far too many cycles.
If you are not interested, please go away and let those of us who are
interested work out the details. So far, I've only seen you put down just
about every proposal without anything constructive coming from your side.
Gregory Stark wrote:
> The current process is about as simple for a
> submitter as it could possibly be:
Yes, but we are not talking about the process for the submitter but the
process for the developer.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
Gregory Stark wrote:
> Yes, if we're just tracking patches or major proposals in a bug tracker.
> The hard part is actually deciding that they're closed.
I am of the opinion that that will be very easy in practice.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
Bruce Momjian wrote:
> That is a nice list, but are these used for bug tracking or patch
> tracking?
In my experience, these two concepts become mostly the same. Just one is
classified "normal" or "critical" and the the other is tagged "wishlist"
and "patch" or "attachment" or something like th
On Sat, Apr 5, 2008 at 12:36 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
>
> Actually, I suggested that to the patch author and he accepted it as a
> good idea:
> http://archives.postgresql.org/pgsql-hackers/2008-04/msg00245.php
>
> so let's see what he comes up with...
>
>
New patch submitted:
http:
On Tuesday 08 April 2008 21:03, Bruce Momjian wrote:
> Bruce Momjian wrote:
> > > Why are such politically touchy decisions being taken in an anonymous,
> > > unarchived forum like IRC, anyway? Especially when what *was*
> > > being publicly discussed was an entirely different change?
> > > http:/
On Thu, 10 Apr 2008 23:21:40 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>
> > Yes Alvaro but that doesn't mean the process should be complicated
> > for the sake of being complicated.
>
> This is all utter BS though. The current process is abou
Alvaro Herrera wrote:
Gregory Stark wrote:
And indeed the closest analogue I can think of to our habit of mailing around
patches is the Linux kernel where people often do post proposed patches and
patches get signed off by a second developer. Each maintainer keeps track on
his own todo lis
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>>> Note that we'll need to add candidate match support to the regular index
>>> scan API as well for that.
>>
>> [ confused... ] Thought you'd done that in this patch?
> No, I onl
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Its about efficiency. If I have to *think* about some kind of process
> that takes cycles away from other more important and interesting things
> like algorithms.
This thread has already consumed far too many cycles.
--
Gregory Stark
Enterpri
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Yes Alvaro but that doesn't mean the process should be complicated for
> the sake of being complicated.
This is all utter BS though. The current process is about as simple for a
submitter as it could possibly be:
1) If you want to send us a patch
On Thu, 10 Apr 2008 16:14:33 -0500
Decibel! <[EMAIL PROTECTED]> wrote:
> On Apr 10, 2008, at 12:52 AM, Brendan Jurd wrote:
> > The typical way to solve this is to have the tracker send an
> > automatic notification email to a list saying "Hey, there's a new
> > ticket at , come and check it out".
"Fabiana Prabhakar" <[EMAIL PROTECTED]> writes:
> I noticed that version 8.3 has a feature "L2 Cache Scan Protection" that is
> described in the website as "New code optimizations prevent thrashing CPU
> caches which slows concurrent queries".
>
> It would be really helpful for me if I could have
On Thu, 10 Apr 2008 12:13:38 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Joshua D. Drake wrote:
>
> > The base requirements for this process must be so simple, so easy,
> > that even if the person has never seen a C patch in his/her life
> > they understand what is trying to be achieved.
>
On Thu, 10 Apr 2008 14:18:52 -0400
Chris Browne <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] ("Joshua D. Drake") writes:
> > The base requirements for this process must be so simple, so easy,
> > that even if the person has never seen a C patch in his/her life
> > they understand what is trying
"Decibel!" <[EMAIL PROTECTED]> writes:
> Am Samstag, 5. April 2008 schrieb Gregory Stark:
>> On Apr 10, 2008, at 7:50 AM, Peter Eisentraut wrote:
>>> I also don't see any point in allowing aliases which call other psql
>>> commands.
>
> Why disallow it? I think it could be very useful.
Well I fe
Gregory Stark wrote:
> And indeed the closest analogue I can think of to our habit of mailing around
> patches is the Linux kernel where people often do post proposed patches and
> patches get signed off by a second developer. Each maintainer keeps track on
> his own todo list of patches to take a
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> Marc G. Fournier wrote:
>> Do other large projects accept patches 'ad hoc' like we do? FreeBSD?
>> Linux? KDE?
>...
> Postfix is the only major project I looked at that didn't have any bug
> tracker
> linked at an obvious location.
Those are us
On Apr 10, 2008, at 12:52 AM, Brendan Jurd wrote:
The typical way to solve this is to have the tracker send an automatic
notification email to a list saying "Hey, there's a new ticket at ,
come and check it out".
And that's part of the issue... "come over to this other place to
actually look
Am Samstag, 5. April 2008 schrieb Gregory Stark:
On Apr 10, 2008, at 7:50 AM, Peter Eisentraut wrote:
I also don't see any point in allowing aliases which call other psql
commands.
Why disallow it? I think it could be very useful. One thing I
sometimes find myself doing is wanting to run a
Hi,
My name is Fabiana Prabhakar. I am a graduate student at Lehigh University.
I have been doing some research using PostgreSQL towards implementing a
cache conscious hash join algorithm.
I noticed that version 8.3 has a feature "L2 Cache Scan Protection" that is
described in the website a
> BTW, I'm pretty sure I have figured out the method for storing minimal
> required binary tree as an array, where adding each page adds exactly
> one upper node. The node added is often not the immediate parent, but is
> always the one needed for covering all nodes.
>
> I just have to write it u
Andrew Chernow wrote:
res = paramexec(conn, param, ...
if(!res)
// check pgconn or pgparam?
// can conn have an old error (false-pos)
We will just always dump the error message into the param. If
PQexecParams fails with a NULL result, we will copy PQerrorMessage over
to param->errMsg.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In the projects I'm involved in, tends to be for used for both purposes ... one
central location for everything ...
- --On Thursday, April 10, 2008 15:22:28 -0400 Bruce Momjian <[EMAIL
PROTECTED]>
wrote:
> Peter Eisentraut wrote:
>> Here is what
Andrew Chernow wrote:
For client_encoding and noticeHooks, the conn can be NULL. Previously,
we copied this info from the source result when conn was NULL.
Looks like we don't need client_encoding. My guess is, in our use case
noticeHooks can probably be NULL for the created result, whe
Peter Eisentraut wrote:
> Here is what everyone else is using:
>
> Kolab - roundup
> GnuPG - roundup
> Python - custom
FWIW Python also uses roundup.
This would be a pointless comment except that I think roundup is a bit
closer to our ways than Bugzilla.
--
Alvaro Herrera
[EMAIL PROTECTED] ("Joshua D. Drake") writes:
> The base requirements for this process must be so simple, so easy, that
> even if the person has never seen a C patch in his/her life they
> understand what is trying to be achieved.
Are you sure about that?
I think that our concern is about the so
Peter Eisentraut wrote:
> Here is what everyone else is using:
>
> FreeBSD - gnats
> Linux - bugzilla
> KDE - bugzilla
> GNOME - bugzilla
> Debian - debbugs
> Ubuntu - launchpad (proprietary)
> Mozilla - bugzilla
> OpenOffice - bugzilla
> Fedora - bugzilla
> Samba - bugzilla
> NTP - bugzilla
> Slo
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
Note that we'll need to add candidate match support to the regular index
scan API as well for that.
[ confused... ] Thought you'd done that in this patch?
No, I only modified the bitmap scan API.
(Heiiki, you don't have a late
Marc G. Fournier wrote:
> Do other large projects accept patches 'ad hoc' like we do? FreeBSD?
> Linux? KDE?
Here is what everyone else is using:
FreeBSD - gnats
Linux - bugzilla
KDE - bugzilla
GNOME - bugzilla
Debian - debbugs
Ubuntu - launchpad (proprietary)
Mozilla - bugzilla
OpenOffice - bu
I have added URLs to your patch to the TODO list:
* Allow data to be pulled directly from indexes
---
Gokulakannan Somasundaram wrote:
> Hi,
> I would like to present the first patch. It currently has the follow
Added to TODO:
* Allow index scans to return matching index keys
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01079.php
---
Heikki Linnakangas wrote:
> Currently amgettuple returns one
Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
PGresult *PQresultDup(
PGconn *conn,
PGresult *res,
int ntups,
int numAttributes,
PGresAttDesc *attDescs);
I don't understand why this is a "dup" operation. How can you "dup"
if you are specifying a new tuple descriptor
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Yeah, and Teodor's point about cleaning up the @@@ hack pretty much
>> seals the deal for me.
> Note that we'll need to add candidate match support to the regular index
> scan API as well for that.
[ confused... ] Thought you'd
Tom Lane wrote:
Yeah, and Teodor's point about cleaning up the @@@ hack pretty much
seals the deal for me.
Note that we'll need to add candidate match support to the regular index
scan API as well for that.
Unless anyone has objections, I will review and apply Heikki's patch
http://archives
Yeah, just as messy as I feared :-(. My inclination for the first pass
would be to just make it a per-AM flag in pg_am. We could always
complicate matters later.
Agree, and the single existing suitable opclass hasn't operation marked with
RECHECK flag.
--
Teodor Sigaev
> Gregory Stark wrote:
> >
> > There's a suspicious ifdef in pg_standby for WIN32 which smells like a
> > kludge
> > added to work around a Windows problem which makes it work but at great
> > expense:
> >
> > #ifdef WIN32
> > /*
> > * Windows reports that the fi
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> Both GIN and GiST make a call of transformation function before indexing
> value.
> I suppose, there is no automatic way to set this flag even in case when type
> of
> storage and type of indexing value are the same.
> So, I see three variant:
> -
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The remaining topics associated with index AMs are closed for this
>> commit fest, unless anyone has specific questions they want discussed
>> right now...
> OK, do you want the items moved to the next commit-fest, discarded, or
> made
GiST too, because type of storage may be differ from type to be indexed. The
same touches GIN too.
Is this the case for *all* GiST and GIN indexes, or might we need a
per-index (rather than per-AM) flag to tell whether the original keys
are available?
Ughm. GiST and GIN are different here. For
Andrew Chernow <[EMAIL PROTECTED]> writes:
> PGresult *PQresultDup(
>PGconn *conn,
>PGresult *res,
>int ntups,
>int numAttributes,
>PGresAttDesc *attDescs);
I don't understand why this is a "dup" operation. How can you "dup"
if you are specifying a new tuple descriptor? I'd h
Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> A bigger issue is whether this is worth applying when nobody seems to be
> >> working on either of the main uses for it (bitmap indexes and GIT
> >> indexes). There seemed to be some possible marginal use for
Tom Lane wrote:
> PQresultErrorMessage at this point --- if you haven't already
> checked the PGresult to be "okay", you should certainly not be
> trying to extract fields from it. So I don't see that you
> are saving any steps here.
Correct, I agree. Our thinking was flawed. The issue we face
Joshua D. Drake wrote:
> On Thu, 10 Apr 2008 11:15:08 -0400
> Aidan Van Dyk <[EMAIL PROTECTED]> wrote:
>
> > Well, only if you want to "pull" the last status (i.e. someone else,
> > not you may have updated it, and you haven't set yourself to be
> > notified on changes). But again, since it's by
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> A bigger issue is whether this is worth applying when nobody seems to be
>> working on either of the main uses for it (bitmap indexes and GIT
>> indexes). There seemed to be some possible marginal use for it in GIST
>> indexes, bu
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> * Proposed change to let both amgetnext and amgetmulti mark returned
>> tuples as "candidate matches", that is in need of rechecking of quals
>> ...
>> indexes). There seemed to be some possible marginal use for it in GIST
>> indexes, but I'm not convin
On Thu, Apr 10, 2008 at 5:27 AM, Ashish Sharma <[EMAIL PROTECTED]> wrote:
> Thanks for the response. Below are the details:
>
> >
> > What queries are you running?
>
> We are running normal SQLs and DMLs. Even simple queries like "select *
> from..." are showing the described behavior.
>
> >
Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
Recap: PQresultDup, PQresultSetFieldDesc and PQresultSetFieldValue.
We feel this approach, which we initially thought wouldn't work, is
better than making pg_result public.
That doesn't seem to me to fit very well with libpq's interna
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Csaba Nagy" <[EMAIL PROTECTED]> writes:
>> For interactive use in the above mentioned scenario you can use the
>> 'screen' command and start as many psqls as needed
> Sure, or you could just start multiple xterms or emacs shell buffers
> (my preferred
Andrew Chernow <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> Surely you would just provide a function to get pqtypes errors separate from
>> libpq errors?
> That's extremely akward. Consider the below.
I'm just as suspicious of this as Greg is. In particular, I really
disagree with PQge
* Joshua D. Drake <[EMAIL PROTECTED]> [080410 11:30]:
> On Thu, 10 Apr 2008 11:15:08 -0400
> Aidan Van Dyk <[EMAIL PROTECTED]> wrote:
>
>
> > > * Where do I comment?
> >
> > In your mail program.
>
> To where? Development discussion is supposed to happen on -hackers but
> a patch is likely on
* Joshua D. Drake <[EMAIL PROTECTED]> [080410 10:24]:
>
> Someone, anyone should be able to look exactly one place for the
> information required to process a patch.
That one place is (and I think always should be, but I'm biased) going
to be the mailling list.
>
* Joshua D. Drake <[EMAIL PROTECTED]> [080410 11:55]:
> On Thu, 10 Apr 2008 11:53:09 -0400
> Aidan Van Dyk <[EMAIL PROTECTED]> wrote:
>
> > I can grab the messageid (or mhonorc url, I've got tools to get the
> > message id out if it), directly open the message in my reader of
> > choice, and have
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > (I wonder what should happen if a message is posted to more than one
> > list.)
>
> That's a good question. I suppose there are actually multiple archive
> entries in that case --- which one is the message-id link taking me to?
The
Andrew Chernow <[EMAIL PROTECTED]> writes:
> Recap: PQresultDup, PQresultSetFieldDesc and PQresultSetFieldValue.
> We feel this approach, which we initially thought wouldn't work, is
> better than making pg_result public.
That doesn't seem to me to fit very well with libpq's internals ---
in part
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> (I wonder what should happen if a message is posted to more than one
> list.)
That's a good question. I suppose there are actually multiple archive
entries in that case --- which one is the message-id link taking me to?
I guess whichever list appears f
Joshua D. Drake wrote:
> The base requirements for this process must be so simple, so easy, that
> even if the person has never seen a C patch in his/her life they
> understand what is trying to be achieved.
I'm pretty sure we don't want a person who has never seen a C patch in
his life anywhere
On Thu, 10 Apr 2008 12:07:43 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > Or :)
>
> > I can open a web browser, go to tracker.postgresql.org,
> > review the list of open patches, click one, download, review,
> > comment, upload new patch if require
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> The message comes up.
>
> Granted... very, very cool that this is all linked, so +1.
>
> But now what?
Now you return, suitably enlightened, to your regularly scheduled life talking
about code (or trackers) on pgsql-hackers and other mailing lists.
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Or :)
> I can open a web browser, go to tracker.postgresql.org,
> review the list of open patches, click one, download, review, comment,
> upload new patch if required, done.
And then no one sees your revised patch (except someone watching the
track
Joshua D. Drake wrote:
> On Thu, 10 Apr 2008 11:17:37 -0400
> Tom Lane <[EMAIL PROTECTED]> wrote:
>
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > > But now what?
> >
> > If you've got substantive comments to make, you make them by replying
> > to the original email, same as it ever was.
On Thu, 10 Apr 2008 11:53:09 -0400
Aidan Van Dyk <[EMAIL PROTECTED]> wrote:
> I can grab the messageid (or mhonorc url, I've got tools to get the
> message id out if it), directly open the message in my reader of
> choice, and have the patch, all the discussion threaded nicely, so I
My mail reade
Bruce Momjian wrote:
> Also, let me add the wiki does not have items that need
> discussion/feedback for this commit-fest. Is that going to be added
> someday?
I take that back. The March wiki has two items that are clearly not
ready to be applied but need discussion that is happening:
On Thu, 10 Apr 2008 11:41:51 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Joshua D. Drake wrote:
>
> > And in looking at this further, if I look at the Column Level
> > privelages patch on the wiki, the archive page goes to a -hackers
> > email.
> >
> > http://archives.postgresql.org/pgsql-
* Joshua D. Drake <[EMAIL PROTECTED]> [080410 11:35]:
> I now need to open my mail client (fair enough, with me it is alt-tab),
> go to my projects-postgresql folder, put a search string in the search
> field, find the correct email, reply to the email with my comments, and
> possibly an updated
Bruce Momjian wrote:
> Also, let me add the wiki does not have items that need
> discussion/feedback for this commit-fest. Is that going to be added
> someday?
Sure, we can create a new section titled "items needing discussion".
--
Alvaro Herrerahttp://www.Comma
"Zeugswetter Andreas OSB SD" <[EMAIL PROTECTED]> writes:
>> ... The really serious problem I've got with it is that
>> it'd foreclose the possibility of returning actual index keys from btree
>> indexes, thus basically killing the usefulness of that idea. I'm not
>> convinced it would offer enough
Aidan Van Dyk wrote:
> > Lastly, how is this sustainable? I don't see anything that is reducing
> > Bruce's workload. (for example)
>
> The only think that will ever reduce Bruce's workload is him trusting
> that things aren't getting overlooked. The value to the work Bruce does
> is that he real
Joshua D. Drake wrote:
> And in looking at this further, if I look at the Column Level
> privelages patch on the wiki, the archive page goes to a -hackers email.
>
> http://archives.postgresql.org/pgsql-hackers/2008-04/msg00049.php
>
> * Do I now respond to the hackers list?
Note that we expec
Le jeudi 10 avril 2008, Gregory Stark a écrit :
> I'm getting interested now. How was __pr_penalty defined? What was the
> declaration you were missing in prefix.c?
In fact __pr_penalty is the internal code called from both the SQL callable
functions (and some other calling sites). The problem wa
On Thu, 10 Apr 2008 11:17:37 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > But now what?
>
> If you've got substantive comments to make, you make them by replying
> to the original email, same as it ever was. The wiki page is an
> index of email th
On Thu, 10 Apr 2008 11:15:08 -0400
Aidan Van Dyk <[EMAIL PROTECTED]> wrote:
> > * Where do I comment?
>
> In your mail program.
To where? Development discussion is supposed to happen on -hackers but
a patch is likely on -patches. Although we are allowed to discuss on
-patches as long as it is
"Dimitri Fontaine" <[EMAIL PROTECTED]> writes:
> It turned around the error was related to the definition of my gpr_penalty()
> function, which I wanted to expose as the GiST "internal" and a SQL callable
> one too (for debugging and tests purpose). I forgot to define the internal
> one in the
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > From what I can see on CPAN (unless I am missing something) DBD::PgSPI
> > hasn't been updated since 2004 and is at version 0.2.
>
> Oh, if it's not a live project then that changes things entirely.
> +1 for just dropping the ment
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> Am Donnerstag, 10. April 2008 schrieb Tom Dunstan:
>> Even so I reckon
>> that would create vastly more noise than signal in the eventual
>> tracker - part of the existing problem has been that wading through
>> list archives is a pain for someone w
> * GIT (Grouped Index Tuple) indexes, which achieve index space savings
> in btrees by having a single index tuple represent multiple heap
tuples
> (on a single heap page) containing a range of key values. I am not
sure
> what the development status is --- Heikki had submitted a completed
> patc
Stefan Kaltenbrunner wrote:
> Gregory Stark wrote:
> > "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> >
> >> The typical way to solve this is to have the tracker send an automatic
> >> notification email to a list saying "Hey, there's a new ticket at ,
> >> come and check it out".
> >
> > Unfortuna
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> But now what?
If you've got substantive comments to make, you make them by replying to
the original email, same as it ever was. The wiki page is an index of
email threads that need attention.
Small comments can just be left on the wiki page, but th
Brendan Jurd wrote:
> > Another is that the email list provides a
> > "push" mechanism for putting the proposed patch under the noses of a
> > bunch of people, a few of whom will hopefully take a sniff ;-).
> > A tracker is very much more of a "pull" scenario where someone has to
> > actively g
Andrew Chernow wrote:
/* Only for results returned by PQresultDup. This
* will append a new tuple to res. A PGresAttValue
* is allocated and put at index 'res->ntups'. This
* is similar to pqAddTuple except that the tuples
* table has been pre-allocated. In our case, ntups
* and numAttr
Warning - my "development" views and experiences are highly e-mail
dependant (i.e. linux-kernel style dependant). So if you don't like
email, you probably shouldn't read my response below.
* Joshua D. Drake <[EMAIL PROTECTED]> [080410 10:48]:
> I click the patch for EXPLAIN progress info:
>
>
On Thu, Apr 10, 2008 at 10:56 AM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Andrew Chernow" <[EMAIL PROTECTED]> writes:
> > How would the caller of getvalues know whether the error was generated by a
> > libpqtypes API call or by a libpq API call (like PQgetvalue)? PQgetf should
> > behave exac
* Bruce Momjian <[EMAIL PROTECTED]> [080410 11:06]:
> I assume you also read this Apache heading:
>
> What if my patch gets ignored?
>
> Because Apache has only a small number of volunteer developers,
> and these developers are often very busy, it is possible that your
>
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Am I supposed to look at the wiki page or bruce pages, or am I supposed
> to replying on the list about something. All of which happen during
> this fest.
We were maintaining status on both pages for this fest, as an experiment
to see which was more
Greg Smith wrote:
> Apache also pushes everything through bugzilla:
> http://httpd.apache.org/dev/patches.html
>
> The interesting quote there is:
>
> "Traditionally, patches have been submitted on the developer's mailing
> list as well as through the bug database. Unfortunately, this has made
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> From what I can see on CPAN (unless I am missing something) DBD::PgSPI
> hasn't been updated since 2004 and is at version 0.2.
Oh, if it's not a live project then that changes things entirely.
+1 for just dropping the mention.
"Andrew Chernow" <[EMAIL PROTECTED]> writes:
> How would the caller of getvalues know whether the error was generated by a
> libpqtypes API call or by a libpq API call (like PQgetvalue)? PQgetf should
> behave exactely as PQgetvalue does, in regards to errors.
Hm. Well I was thinking of errors fr
Joshua D. Drake wrote:
On Thu, 10 Apr 2008 10:45:25 -0400
Tom Lane <[EMAIL PROTECTED]> wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Question for plperl hackers: Should we remove the mention of
DBD::PgSPI from the PL/Perl manual?
It seems like a reasonable suggestion to
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Donnerstag, 10. April 2008 schrieb Tom Lane:
>> Another is that the email list provides a
>> "push" mechanism for putting the proposed patch under the noses of a
>> bunch of people, a few of whom will hopefully take a sniff ;-).
>> A tracker is very
On Thu, Apr 10, 2008 at 04:12:56PM +0200, Magnus Hagander wrote:
> > > my $replace_re =
> > > qr{^([^:\n\$]+\.c)\s*:\s*(?:%\s*: )?\$(\([^\)]+\))\/(.*)\/[^\/]+$};
> > Perhaps you would like to comment it using the x format, so that it
> > doesn't just look like white noise.
>
> That would be
1 - 100 of 153 matches
Mail list logo
