On Thu, 10 Apr 2008, Brendan Jurd wrote:
[Automatic e-mail notification] is trivial to configure in a "real"
tracker. Less so for a wiki page, but it could still be accomplished
with the careful application of script-fu.
Anyone who is interested can sign up for e-mail notification whenever a
Bruce Momjian wrote:
Fine with me, but I was hoping someone would come up with an idea that
would reduce what I need to do, like perhaps a new vacuum cleaner. ;-
Bruce et al.,
If you need a reasonably (modestly?) intelligent person to put to work
helping, I am more than willing to work wit
"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".
Unfortunately that is the typical way to "solve" this. And it's awful.
It's like the
On Thu, 2008-04-10 at 05:03 +0930, Shane Ambler wrote:
> I do think it is useful for more than typo's in the \join command. What
> about a slip where you forget to \g& the command. Or you start a query
> that seems to be taking too long, background it and look into what is
> happening. This woul
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".
Unfortunately that is the typical way to "solve" this. And it's aw
> I find myself doing this frequently with any long-running command,
> but currently it's a PITA because I'd doing it at the shell level and
> firing up a new psql: more work than should be necessary, and psql
> sometimes gets confused when you resume it from the background in
> interactive
Thanks for the response. Below are the details:
> > On Wed, 2008-04-09 at 18:33 +0530, Ashish Sharma wrote:
> > > Hi,
> > >
> Hi, all!!
> > > The setup in question includes PostGRESQL v8.2.4, Java based web
> > > servers and MS.NET based web servers. Following is the fuzzy
> > > sit
"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 setup).
But I'm sure there are people who would
On Thu, Apr 10, 2008 at 1:07 PM, Gregory Stark <[EMAIL PROTECTED]> 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".
>
> Unfortunately that is the typical way to "s
On Thu, Apr 10, 2008 at 3:03 PM, Stefan Kaltenbrunner
<[EMAIL PROTECTED]> wrote:
> well what about having the tracker being subscribed to the list and let it
> create a bug/patch/ticket id automatically for new mails - that way all
> stuff is automatically tracked ? - That way it can be categoriz
Is there any patch available for this one?
I'm encountering troubles with some JDBC queries and I'd like to test
it before asking some help on the JDBC list.
Thanks.
Tom
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.pos
Tom Lane schrieb:
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
I've run into a couple cases now where it would be helpful to easily
assign an already-existing unique index as a primary key.
You need to present a more convincing use-case than this unsupported
assertion. There's hardly
* 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 convinced that's a sufficient reason to complicate
the APIs.
On Thu, Apr 10, 2008 at 3:41 PM, Gregory Stark <[EMAIL PROTECTED]> wrote:
> >> What's wrong with a patch submitter submitting a patch to a tracker,
> >> but then emailing the list for actual discussion?
>
> What's what we have today with the wiki. We don't need any special software
> to
> do t
It's pretty easy to test.
prepare the query
and
run explain analyze on the prepared statement.
Dave
On 10-Apr-08, at 5:47 AM, Thomas Burdairon wrote:
Is there any patch available for this one?
I'm encountering troubles with some JDBC queries and I'd like to
test it before asking some help o
Tom Dunstan wrote:
On Thu, Apr 10, 2008 at 1:07 PM, Gregory Stark <[EMAIL PROTECTED]> 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".
Unfortunately that is the typic
"Stefan Kaltenbrunner" <[EMAIL PROTECTED]> writes:
> Tom Dunstan wrote:
>> What's wrong with a patch submitter submitting a patch to a tracker,
>> but then emailing the list for actual discussion?
What's what we have today with the wiki. We don't need any special software to
do that. It does re
Tom Dunstan wrote:
On Thu, Apr 10, 2008 at 3:03 PM, Stefan Kaltenbrunner
<[EMAIL PROTECTED]> wrote:
well what about having the tracker being subscribed to the list and let it
create a bug/patch/ticket id automatically for new mails - that way all
stuff is automatically tracked ? - That way it
PFC wrote:
About the FSM :
Would it be possible to add a flag marking pages where all tuples
are visible to all transactions ? (kinda like frozen I think)
Ah, the visibility map. That's another line of discussion. The current
plan is to not tie that to the FSM, but implement it se
* Dumb Optimization #1:
- Add executorFunc function pointer to struct PlanState
- in ExecProcNode.c -> ExecProcNode() :
- upon first execution, set executorFunc to the function corresponding to
node type
- next calls use function pointer
Effect : removes a switch (nodeTag(no
Hannu Krosing wrote:
On Wed, 2008-04-09 at 21:09 +0300, Heikki Linnakangas wrote:
Hannu Krosing wrote:
Saving 1 byte is an atomic op
Unfortunately, it's not. Most if not all modern CPUs will perform one
byte modification as "load word" + "modify word" + "save word".
Hmm, maybe we I should ch
Joshua D. Drake escribió:
> On Wed, 09 Apr 2008 23:01:30 -0300
> "Marc G. Fournier" <[EMAIL PROTECTED]> wrote:
>
> > I could see it with older submitters, who are used to just sending an
> > email, but the new guys will go with whatever procedure is laid out
> > for them *as long as* it is enforce
Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
What parts of PGconn/PGresult do you need to touch that aren't exposed
already?
Don't need direct access to PGconn at all.
Oh, good, that makes things much easier.
Shoot! Feels like you always miss something.
The patch uses PGc
Am Samstag, 5. April 2008 schrieb Gregory Stark:
> Regardless of whether we go ahead with this (and I'm not fond of it
> primarily because I want \c& to "work"), I think we would still be better
> off keeping the aliases in a separate namespace from psql commands and
> having an explicit command fo
Stefan Kaltenbrunner wrote:
> well what about having the tracker being subscribed to the list and let
> it create a bug/patch/ticket id automatically for new mails - that way
> all stuff is automatically tracked ? - That way it can be categorized in
> the course of the following discussion b
Tom Lane escribió:
> Obviously there are virtues on both sides of this, which is why I think
> we need both mechanisms. The simplest way to integrate them AFAICS
> is to use the tracker as an index on the email traffic.
Agreed.
--
Alvaro Herrerahttp://www.Comman
Martin Edlman wrote:
> |> I don't want to rewrite whole trigger to plPerl as I would have to use
> |> DBD-PgSPI.
> |
> | Huh? Certainly not -- there are functions in PL/Perl for this. See
> | spi_exec_query in
> | http://www.postgresql.org/docs/8.3/static/plperl-database.html
>
> Oh, I see. I ha
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> But other people do want to use it. If it is too confusing for you, don't
> use
> it. That's what's nice about this feature: If you don't use it, it doesn't
> affect you at all.
Ah but I would use it. In particular the query I found myself wr
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
well what about having the tracker being subscribed to the list and let
it create a bug/patch/ticket id automatically for new mails - that way
all stuff is automatically tracked ? - That way it can be categorized in
the course of the f
"Andrew Chernow" <[EMAIL PROTECTED]> writes:
> Shoot! Feels like you always miss something.
>
> The patch uses PGconn's PQExpBuffer to set errors on a conn. Currently, there
> is no access to this buffer other than PQerrorMessage. Is the below okay?
Surely you would just provide a function to
Gregory Stark wrote:
> Bug/request trackers are great tools, but they're just tools. They don't
> replace actually having to do the work. Given the really trivial number of
> patches we're dealing with really just adding entries to a wiki page is a
> perfectly reasonable solution.
+1
--
Alvaro
Andrew Dunstan wrote:
> The consensus last year among a group of us who examined a number of
> tracker systems was, IIRC, that Bugzilla had the best combination of
> features that people had requested. (And it does have some email
> interaction). Stefan Kaltenbrunner did some work on putting u
Gregory Stark wrote:
"Andrew Chernow" <[EMAIL PROTECTED]> writes:
Shoot! Feels like you always miss something.
The patch uses PGconn's PQExpBuffer to set errors on a conn. Currently, there
is no access to this buffer other than PQerrorMessage. Is the below okay?
Surely you would just prov
Alvaro Herrera wrote:
Andrew Dunstan wrote:
The consensus last year among a group of us who examined a number of
tracker systems was, IIRC, that Bugzilla had the best combination of
features that people had requested. (And it does have some email
interaction). Stefan Kaltenbrunner did some
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Stefan Kaltenbrunner wrote:
well what about having the tracker being subscribed to the list and
let it create a bug/patch/ticket id automatically for new mails -
that way all stuff is automatically tracked ? - That way it can be
categorized i
On Thu, 10 Apr 2008 09:29:10 -0400
Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> >
>
> The issue frankly is not tracker features. The issue is who is going
> to maintain it, doing pruning and triage as necessary. No tracker
> looks after itself.
If you provide a reasonable interface to manageme
On Thu, 10 Apr 2008 09:36:23 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Gregory Stark wrote:
>
> > Bug/request trackers are great tools, but they're just tools. They
> > don't replace actually having to do the work. Given the really
> > trivial number of patches we're dealing with really j
Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
> > I just tried the MSVC build on a system with ActiveState Perl 5.10,
> > and it doesn't work. Some quick debugging before I downgraded to
> > 5.8 showed that this regexp in Project.pm line 262:
> > my $replace_re =
> > qr{^([^:\n\$]+\.c)\s
Joshua D. Drake wrote:
> On Thu, 10 Apr 2008 09:36:23 -0400
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> > Gregory Stark wrote:
> >
> > > Bug/request trackers are great tools, but they're just tools. They
> > > don't replace actually having to do the work. Given the really
> > > trivial number
Gregory Stark escribió:
> Ah but I would use it. In particular the query I found myself writing *all*
> the time over and over again in Oracle was:
>
> select count(*),n from (select count(*) as n from group by ) group
> by n
>
> I can type it out now from finger-memory without even thinking a
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 wanting to know the current status
> of a patch. I can'
I guess I'll keep talking to myself, but...
Le mercredi 02 avril 2008, Dimitri Fontaine a écrit :
> My previous tests were only done with REL8_2_STABLE cvs branch, I just
> redone some tests with REL8_3_STABLE and got no error. The index is still
> buggy, in the sense some requests returns differe
Am Donnerstag, 10. April 2008 schrieb Andrew Dunstan:
> The issue frankly is not tracker features. The issue is who is going to
> maintain it, doing pruning and triage as necessary.
I'll do it. Now just give me one I can maintain.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
So, Greg, after all this feedback, are you going to rework the patch?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscr
On Thu, 10 Apr 2008 10:15:29 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > I don't think so because it really isn't a change from what we have
> > now. There isn't much difference from having a wiki page versus just
> > having conversations on the patch list and moving email around.
>
> If
Am Donnerstag, 10. April 2008 schrieb Stefan Kaltenbrunner:
> the setup is more or less complete and the integration part was with the
> community login system (same we have now for wiki.postgresql.org) by
> adding a postgresql authentication backend as well as some experimental
> modifications to
Joshua D. Drake wrote:
> On Thu, 10 Apr 2008 10:15:29 -0400
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> > > I don't think so because it really isn't a change from what we have
> > > now. There isn't much difference from having a wiki page versus just
> > > having conversations on the patch lis
On Thu, 10 Apr 2008 10:28:55 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > I admit, I didn't use the wiki page because I got tired of trying to
> > figure out which page, or list I should be looking at. I was still
> > get js-kit replies from Bruces pages this week.
>
> I don't know what yo
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 much more of a "pull" scenario where someone has t
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 me, since perl database users
probably already know DBD and don't have to learn something new if they
go that wa
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> So, Greg, after all this feedback, are you going to rework the patch?
I'm a bit busy now but yes, eventually.
I had in mind that it would probably make sense to start over, stealing code
as appropriate. The main thing is that the logic is a bit twi
On Thu, 10 Apr 2008 07:30:32 -0700
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote:
> > I don't know what you're talking about. There are two wiki pages,
> > one for the March commitfest and one for May. How can you be
> > confused on which one are you supposed to look at?
> >
> > http://wiki.postg
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 me, since perl database users
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
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
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
"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" <[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.
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
* 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
>
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
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:
>
>
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
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
"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
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
> * 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
"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
"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
"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
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
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
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
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
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
"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
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
* 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
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-
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: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
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.
"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" <[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.
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
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
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
* 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
* 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: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
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
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
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
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.
>
> >
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
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
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
1 - 100 of 153 matches
Mail list logo
