Bruce Momjian wrote:
> Why aren't more people involved? Is this such a thankless task? I
> am starting to think so.
I can tell you exactly what my problem is. The tools are terrible. In
projects with a useful issue tracking system I can take small chunks
out of my day to contribute to speci
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There is *no* credible use case for this (hint: MOVE FORWARD/BACKWARD
>> ALL does not need this to work for >2G tables).
> Already done because of bad coding. You want the TODO item removed too?
As I said, I see no use case for it.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Jim C. Nasby wrote:
>> On Sat, Sep 02, 2006 at 07:22:45PM +0100, Gregory Stark wrote:
>>> Has anyone considered adding vi/vim options to the files themselves?
>>
>> Yeah, which is the real question... do people think it's worth it enough
>> to move towar
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Peter has made it pretty clear that he didn't care for the
>> refactorization aspect of that patch.
> Peter asked why it was done, a good answer was given, and Peter did not
> reply.
Au contraire, he's reiterated since then that he di
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Uh, were are we in fixing/reviewing this?
It's dead for 8.2 --- Andrew's complaints are pretty serious at both
the conceptual and implementation levels, and there's been no sign of
discussion about how to fix them.
regards, tom l
I just spent 1/2 hour fixing the multi-value UPDATE
patch for the code drift caused by UPDATE/RETURNING. The patch is a
simple grammar macro. Any coder could have taken that, reviewed it, and
applied it, but no one did.
Perhaps that's because nobody but you wanted it to go in.
We got tons o
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Fri, Sep 01, 2006 at 12:36:11PM -0400, Alvaro Herrera wrote:
>> Whether a table is "bootstrap" or not doesn't seem useful to me.
> Something that might be handy would be a method to determine if an
> object is a system object or not (perhaps what the
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > ... The GUC comment/default patch had tons of
> > emails, but no other committers got involved to review or commit the
> > patch. Peter, who knows GUC well, looked at it, but said he didn't
> > review it enough.
>
> Peter has made i
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> If we do it, basically the response to anyone who complains about loss
>> of performance should be "fix your function to be marked stable or
>> immutable, as appropriate".
> Agreed. Are we doing this, or is it a TODO?
It's done:
http://archives.postgr
Bruce Momjian <[EMAIL PROTECTED]> writes:
> ... The GUC comment/default patch had tons of
> emails, but no other committers got involved to review or commit the
> patch. Peter, who knows GUC well, looked at it, but said he didn't
> review it enough.
Peter has made it pretty clear that he didn't
Christopher Browne wrote:
Oops! [EMAIL PROTECTED] ("Jim C. Nasby") was seen spray-painting on a wall:
On Thu, Aug 31, 2006 at 10:33:36AM -0400, Chris Browne wrote:
What's up there? It has been down all week.
We're trying to get the Slony-I 1.2 release out, so we can then
migrate over to pgFou
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> This patch has broken half the buildfarm, and I've still not seen a
> >> rationale why we need to make such a change at all.
>
> > Fixed with attached patch. The use case for this was not FETCH, but
> > MOVE for > 2gig tables.
>
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> This patch has broken half the buildfarm, and I've still not seen a
>> rationale why we need to make such a change at all.
> Fixed with attached patch. The use case for this was not FETCH, but
> MOVE for > 2gig tables.
There is *no* credible use case
Andrew Dunstan wrote:
>
> We don;t have many buildfarm members testing ECPG yet, but at several
> are broken. Not sure why yet.
>
> see
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=agouti&dt=2006-09-03%2002:15:01
>
> for example
It is the LIMIT/OFFSET patch changes to gram.y. I am loo
Oops! [EMAIL PROTECTED] ("Jim C. Nasby") was seen spray-painting on a wall:
> On Thu, Aug 31, 2006 at 10:33:36AM -0400, Chris Browne wrote:
>> What's up there? It has been down all week.
>>
>> We're trying to get the Slony-I 1.2 release out, so we can then
>> migrate over to pgFoundry. But that
We don;t have many buildfarm members testing ECPG yet, but at several
are broken. Not sure why yet.
see
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=agouti&dt=2006-09-03%2002:15:01
for example
cheers
andrew
---(end of broadcast)---
TIP
Teodor Sigaev wrote:
> > What does that option do? Is it practical to enable it for the entire
> > backend?
> From docs:
> Disables inline expansion of standard library or intrinsic functions.
>
> > And isn't this a straightforward compiler bug they should be notified
> > about?
> What's a choice
Andrew Dunstan wrote:
Peter Eisentraut wrote:
Greg Sabino Mullane wrote:
There are a number of reasons for this, not least of which is the
enormous and ever-changing requirements such a system would have to
have.
The buildfarm is an excellent example of this.
The build farm
Bruce Momjian wrote:
Joshua D. Drake wrote:
Bruce Momjian wrote:
Added to TODO:
* Simplify ability to create partitioned tables
This would allow creation of partitioned tables without requiring
creation of rules for INSERT/UPDATE/DELETE, and constraints for
Andreas Pflug wrote:
> Bruce Momjian wrote:
> >
> > Done, because most people will turn autovacuum on, even if it isn't on
> > by default.
> >
> I wonder how many distros will turn on autovacuum as well, making it the
> de-facto standard anyway.
Win32 already does.
--
Bruce Momjian [EMAIL
Jim C. Nasby wrote:
On Sat, Sep 02, 2006 at 07:22:45PM +0100, Gregory Stark wrote:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
Has anyone considered adding vi/vim options to the files themselves?
Granted, not a trivial task, but it would ensure anyone using vim would
have the correct
Bruce Momjian wrote:
>
> Done, because most people will turn autovacuum on, even if it isn't on
> by default.
>
I wonder how many distros will turn on autovacuum as well, making it the
de-facto standard anyway.
Regards,
---(end of broadcast)---
Peter Eisentraut wrote:
Greg Sabino Mullane wrote:
There are a number of reasons for this, not least of which is the
enormous and ever-changing requirements such a system would have to
have.
The buildfarm is an excellent example of this.
The build farm is not an example of
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Log Message:
> ---
> Change FETCH/MOVE to use int8.
This patch has broken half the buildfarm, and I've still not seen a
rationale why we need to make such a change at all.
regards, tom lane
---(en
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > Added to TODO:
> >
> > * Simplify ability to create partitioned tables
> >
> > This would allow creation of partitioned tables without requiring
> > creation of rules for INSERT/UPDATE/DELETE, and constraints for
> > rapid pa
On Fri, Sep 01, 2006 at 12:36:11PM -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > Zdenek Kotala <[EMAIL PROTECTED]> writes:
> > > I little bit enhanced overview catalog tables. I added two new columns.
> > > First one is OID of catalog table and second one contains attributes
> > > which dete
Bruce Momjian wrote:
Added to TODO:
* Simplify ability to create partitioned tables
This would allow creation of partitioned tables without requiring
creation of rules for INSERT/UPDATE/DELETE, and constraints for
rapid partition selection. Options could i
Added to TODO:
* Simplify ability to create partitioned tables
This would allow creation of partitioned tables without requiring
creation of rules for INSERT/UPDATE/DELETE, and constraints for
rapid partition selection. Options could include range and hash
On Thu, Aug 31, 2006 at 06:29:50PM -0400, Tom Lane wrote:
> For backwards compatibility we should probably say that this automatic
> lifting of base-table defaults happens only if the INSERT rule is
> implicitly generated ... if you write a manual INSERT rule you need
> manual defaults too. Or sho
Tom Lane wrote:
> [EMAIL PROTECTED] (Peter Eisentraut) writes:
> > Revert change to turn autovacuum on by default.
>
> It looks like you reverted that whole patch including the changes to the
> default autovacuum threshold/scale parameters. I'd be inclined to keep those.
Re-added those changes t
Peter Eisentraut wrote:
> Guillaume Smet wrote:
> > IMHO, we shoud also change superuser_reserved_connections from 2 to 3
> > because one of the connections will be used by autovacuum.
>
> Yes, good point.
Done, because most people will turn autovacuum on, even if it isn't on
by default.
--
B
No, since my time is up in the air at the moment, I've bowed out for now.
Once I get settled at Surgient, I might take it up again, but not right now.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jim C. Nasby
Sent: Saturday, September 02, 2006 5:42
Sounds reasonable to me.
Regards, Dave
-Original Message-
From: "Martijn van Oosterhout"
To: "Dave Page"
Cc: pgsql-hackers@postgresql.org; "PostgreSQL WWW" <[EMAIL PROTECTED]>
Sent: 02/09/06 23:08
Subject: Re: [HACKERS] Developer's Wiki
On Sat, Sep 02, 2006 at 08:33:41PM +0100, Dave Pa
On Thu, Aug 31, 2006 at 10:33:36AM -0400, Chris Browne wrote:
> What's up there? It has been down all week.
>
> We're trying to get the Slony-I 1.2 release out, so we can then
> migrate over to pgFoundry. But that doesn't working terribly well
> when gBorg's down...
Speaking of which, what's th
On Fri, Sep 01, 2006 at 10:18:37AM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> >> The server has to prepare the query sometime. The v3 protocol just gives
> >> you
> >> control over when that happens, but it doesn't force you to do it at any
> >> particular time.
>
> > Not really.
On Sat, Sep 02, 2006 at 08:33:41PM +0100, Dave Page wrote:
> I have now moved the wiki installation to:
>
> http://developer.postgresql.org/
Ok, it looks like pages can be arranged hierarchically.
It would seems like pages named:
Todo:
would be a good idea for detailed info on todo items (and
Jim C. Nasby wrote:
> On Sat, Sep 02, 2006 at 07:22:45PM +0100, Gregory Stark wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> >
> > > Has anyone considered adding vi/vim options to the files themselves?
> > > Granted, not a trivial task, but it would ensure anyone using vim would
> > > hav
Thanks. Yes, it is need for two reasons. In 8.2 you can set
standard_conforming_strings to on, meaning \' is really treated as \ and
', and because some encodings now can't support \' for security reasons,
though I don't think tsearch2 supports those multibyte encodings.
Anyway, applied to 8.2
On Sat, Sep 02, 2006 at 07:22:45PM +0100, Gregory Stark wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>
> > Has anyone considered adding vi/vim options to the files themselves?
> > Granted, not a trivial task, but it would ensure anyone using vim would
> > have the correct settings. I don't
On Fri, Sep 01, 2006 at 04:14:32PM +0100, Gregory Stark wrote:
> >> Interesting thought. It might be worth trying. But my big question: is
> >> all this testing and counting actually going to be faster than just
> >> replanning? Postgresql's planner is not that slow.
> >
> > In the best case (which
So we want to replace the isbn in /contrib with this in 8.2?
---
Andrew Dunstan wrote:
> Michael Glaesemann wrote:
> >
> > On Aug 22, 2006, at 2:52 , Bruce Momjian wrote:
> >
> >>
> >> Do we want to replace our /contrib/isbn
Gregory Stark kirjoitti:
[aside, that said that may be a useful feature to have: a user option
to use
our internal heap sort instead of qsort. I'm thinking of users on
platforms
where libc's qsort either performs poorly or is buggy. Since we have
all the
code for heap sort there already anyway
Tom Lane wrote:
> "Jaime Casanova" <[EMAIL PROTECTED]> writes:
> >>> There's been some talk about prohibiting flattening if there are any
> >>> volatile functions in the subselect's targetlist, but nothing's been
> >>> done about that.
>
> > BTW, can you think in a good name for a GUC for this?
>
I have now moved the wiki installation to:
http://developer.postgresql.org/
Where it is currently available for use by any hackers for non-end-user
related activities. I haven't changed Greg's original configuration at all
so it is still open for use by anyone at present, however I have added an
On 2/9/06 20:16, "Martijn van Oosterhout" wrote:
> On Sat, Sep 02, 2006 at 06:38:30PM +0100, Dave Page wrote:
>> The wiki will be going shortly as it's not been setup in the way that was
>> agreed, nor is it being used for it's intended purpose. I'll put it right
>> when I get time from dealin
On Sat, Sep 02, 2006 at 06:38:30PM +0100, Dave Page wrote:
> The wiki will be going shortly as it's not been setup in the way that was
> agreed, nor is it being used for it's intended purpose. I'll put it right
> when I get time from dealing with releases of everything I seem to be
> involved in.
Martijn van Oosterhout wrote:
On Sat, Sep 02, 2006 at 06:18:13PM +0200, Lukas Kahwe Smith wrote:
We have a wiki already:
http://wiki.postgresql.org/
I must have missed the annoucement, oh well...
Now I'm only familiar with twiki so maybe this sounds silly but:
wiki.postgresql.org is dead. :
On Wed, Aug 30, 2006 at 09:48:01PM -0400, Alvaro Herrera wrote:
> Andrew Dunstan wrote:
>
> > Looking at this further, I am wondering if it would not be better to put
> > sample .emacs and .vimrc files in the source (in, say, src.tools).
>
> What does people use in .vimrc? Mine has simply this:
Uh, I have a problem with the README copyright:
+sslinfo - information about current SSL certificate for PostgreSQL
+==
+Copyright (c) 2006 Cryptocom LTD
+Author: Victor Wagner <[EMAIL PROTECTED]>
On 2/9/06 17:18, "Lukas Kahwe Smith" <[EMAIL PROTECTED]> wrote:
> Peter Eisentraut wrote:
>> Martijn van Oosterhout wrote:
>>> I remember something about setting up a wiki for a todo list and pie
>>> in the sky list. I thought it had promise, but until the wiki is
>>> there we won't know...
>>
On 2/9/06 16:42, "Tom Lane" <[EMAIL PROTECTED]> wrote:
> BTW, another "output" thing you might consider is "having draft release
> notes ready-to-go on demand". Currently, Bruce prepares the release
> notes on the basis of a very tedious scan of the CVS commit logs.
> If this sort of stuff we
Bruce Momjian wrote:
It seems that you have been the only busy bee so far, and we definitely
need more for this to work.
Yea, I was afraid that was the answer. :-(
But we have a few volunteers, like me for example.
Now don't say "I was afraid that was the answer" again or I might feel
insu
Tom Lane wrote:
> I'd be less unhappy with this patch if the variable were not marked
> GUC_REPORT. That is what gives it nontrivial cost: it's adding a couple
> dozen bytes to every connection startup exchange, for data that's 100%
> redundant with data already being transmitted.
>
> The argumen
On Sat, Sep 02, 2006 at 06:18:13PM +0200, Lukas Kahwe Smith wrote:
> We have a wiki already:
> http://wiki.postgresql.org/
I must have missed the annoucement, oh well...
Now I'm only familiar with twiki so maybe this sounds silly but:
Does it support sections? Like can you have a developer secti
Bruce Momjian wrote:
Lukas Kahwe Smith wrote:
Robert Treat wrote:
No offense, a whole lot of this thread seems to be positioned that way, but
the real problem seems to be we do not have enough patch reviewers. ISTM the
questions we should be asking are who can actually help out with patch re
Tom Lane wrote:
> I'd be less unhappy with this patch if the variable were not marked
> GUC_REPORT. That is what gives it nontrivial cost: it's adding a couple
> dozen bytes to every connection startup exchange, for data that's 100%
> redundant with data already being transmitted.
Wow, that is ba
Lukas Kahwe Smith wrote:
> Bruce Momjian wrote:
> > Lukas Kahwe Smith wrote:
> >> Robert Treat wrote:
> >>
> >>> No offense, a whole lot of this thread seems to be positioned that way,
> >>> but
> >>> the real problem seems to be we do not have enough patch reviewers. ISTM
> >>> the
> >>> ques
I'd be less unhappy with this patch if the variable were not marked
GUC_REPORT. That is what gives it nontrivial cost: it's adding a couple
dozen bytes to every connection startup exchange, for data that's 100%
redundant with data already being transmitted.
The arguments that were made in favor o
Ühel kenal päeval, L, 2006-09-02 kell 11:20, kirjutas Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Do you have anyone specific in mind who should also do the review ?
>
> I went through the commit log for plpython.c to see who'd be a likely
> prospect, and was dismayed to realize that
Joshua D. Drake wrote:
That wiki is wrong. :) It was set up wrong and configured wrong. It was
supposed to be for developers only.
There is also another wiki that is a trac based that was set up at dave
pages request (for slaves_to_www).
Setup something better, until then we can start using
Peter Eisentraut wrote:
Since the buildfarm is such an integral part of the development process
now, could we get it an enhanced URL like buildfarm.postgresql.org?
All we have to do is point the DNS :), I can make the apache changes.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL
Lukas Kahwe Smith wrote:
Peter Eisentraut wrote:
Martijn van Oosterhout wrote:
I remember something about setting up a wiki for a todo list and pie
in the sky list. I thought it had promise, but until the wiki is
there we won't know...
I think the wiki is the prerequisite for many ideas about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Holy crap, Batman! This database can do
>
> INSERT INTO foo VALUES (1,1, 'so long'), (42, 2, 'and thanks'),
> (142857, 3, 'for all the fish')
>
> now! We should be talking to more people about that!
>
> That will make some MySQL users happy at le
Greg Sabino Mullane wrote:
> I've been thinking about this a lot since before the Summit, and the
> only solution I see is to design something specifically for us.
> Rather than get bogged down in details about how it will work and
> what technologies it will be using, I'd like to share my ideas on
Since the buildfarm is such an integral part of the development process
now, could we get it an enhanced URL like buildfarm.postgresql.org?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 9: In versions be
Lukas Kahwe Smith wrote:
> Robert Treat wrote:
>
> > No offense, a whole lot of this thread seems to be positioned that way, but
> > the real problem seems to be we do not have enough patch reviewers. ISTM
> > the
> > questions we should be asking are who can actually help out with patch
> >
Greg Sabino Mullane wrote:
> There are a number of reasons for this, not least of which is the
> enormous and ever-changing requirements such a system would have to
> have.
> The buildfarm is an excellent example of this.
The build farm is not an example of this. There isn't any build-farm
soft
Greg Sabino Mullane wrote:
Yes, maintaining it will be a royal pain in the butt. But my theory has
been "if you build it, they will come". It will require a lot of human
interaction, as automation only takes you so far, especially when trying
to parse mailing list messages. But if we eventually
Peter Eisentraut wrote:
Martijn van Oosterhout wrote:
I remember something about setting up a wiki for a todo list and pie
in the sky list. I thought it had promise, but until the wiki is
there we won't know...
I think the wiki is the prerequisite for many ideas about alternative
tracking and
Robert Treat wrote:
> On Saturday 02 September 2006 07:14, David Fetter wrote:
> > On Fri, Sep 01, 2006 at 09:46:02PM -0400, Bruce Momjian wrote:
> > > Peter Eisentraut wrote:
> > > > Bruce Momjian wrote:
> > > > > It pulls my a mailbox file I use, and it does instant updates as
> > > > > soon as I
Robert Treat wrote:
No offense, a whole lot of this thread seems to be positioned that way, but
the real problem seems to be we do not have enough patch reviewers. ISTM the
questions we should be asking are who can actually help out with patch review
and then ask those people why they haven't
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane sagely noted:
No bug/issue tracker, or anything else, is going to be successful unless
somebody commits enough time to make it so. I've noted a whole lot of
enthusiasm for having a tracker in these recent discus
Tom Lane wrote:
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
Additionally, what problem is accepting incremental patches supposed
to solve?
Keeping the individual patches reviewable is one useful goal.
We may be talking at cross-purposes here. The sort of thing I think
Alvaro is imagining
On Friday 01 September 2006 19:42, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > On Fri, 1 Sep 2006, Tom Lane wrote:
> >> My feeling is that we ought to bounce bitmap indexes and updatable views
> >> as not being ready, accept all the contrib stuff, and try to get the
> >> other it
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut wrote:
> >> Both createuser and vacuumdb provide the same feedback as the
> >> corresponding SQL commands.
> >>
> >> The more I think about it, the patch that just went in is an outright
> >> mistake.
>
> > Well, w
Robert Treat wrote:
> On Saturday 02 September 2006 11:42, Tom Lane wrote:
> > BTW, another "output" thing you might consider is "having draft release
> > notes ready-to-go on demand". Currently, Bruce prepares the release
> > notes on the basis of a very tedious scan of the CVS commit logs.
> > I
Tom Lane wrote:
> "Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> > I've been thinking about this a lot since before the Summit, and the
> > only solution I see is to design something specifically for us.
>
> Well, nobody's going to accuse you of thinking too small ;-). Sounds
> great to me,
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
> Additionally, what problem is accepting incremental patches supposed
> to solve?
Keeping the individual patches reviewable is one useful goal.
We may be talking at cross-purposes here. The sort of thing I think
Alvaro is imagining is something li
On Saturday 02 September 2006 11:42, Tom Lane wrote:
> BTW, another "output" thing you might consider is "having draft release
> notes ready-to-go on demand". Currently, Bruce prepares the release
> notes on the basis of a very tedious scan of the CVS commit logs.
> If this sort of stuff were bein
Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Do you have anyone specific in mind who should also do the review ?
>
> I went through the commit log for plpython.c to see who'd be a likely
> prospect, and was dismayed to realize that basically no one has done
> any serious work on
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> I've been thinking about this a lot since before the Summit, and the
> only solution I see is to design something specifically for us.
Well, nobody's going to accuse you of thinking too small ;-). Sounds
great to me, though, if you think you can
On Sep 2, 2006, at 11:28 AM, Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Here's a completely novel idea: accept incremental patches.
I don't think it's as novel as all that --- personally I've always
preferred to tackle large projects incrementally.
I think that accepting in
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Here's a completely novel idea: accept incremental patches.
I don't think it's as novel as all that --- personally I've always
preferred to tackle large projects incrementally.
> I've been bitten by having stuff rejected because there was no immediate
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Do you have anyone specific in mind who should also do the review ?
I went through the commit log for plpython.c to see who'd be a likely
prospect, and was dismayed to realize that basically no one has done
any serious work on it since the original autho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane sagely noted:
> No bug/issue tracker, or anything else, is going to be successful unless
> somebody commits enough time to make it so. I've noted a whole lot of
> enthusiasm for having a tracker in these recent discussions, but a
> remarkab
Ühel kenal päeval, L, 2006-09-02 kell 10:25, kirjutas Tom Lane:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
> > Log Message:
> > ---
> > Allow PL/python to return composite types and result sets
>
> Yah know, I've been asking for weeks for someone familiar with plpython
> to review that.
Tom Lane wrote:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
> > Add new variable "server_version_num", which is almost the same as
> > "server_version" but uses the handy PG_VERSION_NUM which allows apps to
> > do things like if ($version >= 80200) without having to parse apart the
> > value of ser
Tom Lane wrote:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
> > Log Message:
> > ---
> > Allow PL/python to return composite types and result sets
>
> Yah know, I've been asking for weeks for someone familiar with plpython
> to review that. Have our review standards just dropped to "commi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> Both createuser and vacuumdb provide the same feedback as the
>> corresponding SQL commands.
>>
>> The more I think about it, the patch that just went in is an outright
>> mistake.
> Well, we had a lot of discussion when thi
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Add new variable "server_version_num", which is almost the same as
> "server_version" but uses the handy PG_VERSION_NUM which allows apps to
> do things like if ($version >= 80200) without having to parse apart the
> value of server_version themselves.
I
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom, should I apply this patch now? Are you still considering other
> options for this?
Please wait. This issue is very far down the to-list in terms of size
or significance ... but I'll get to it.
regards, tom lane
--
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Log Message:
> ---
> Allow PL/python to return composite types and result sets
Yah know, I've been asking for weeks for someone familiar with plpython
to review that. Have our review standards just dropped to "commit it
and see what happens?"
Lukas Kahwe Smith <[EMAIL PROTECTED]> writes:
>> For example I have no expertise in coding on Postgres, but I think I
>> would be able to collect information from this mailinglist (like specs,
>> url's etc.) and put them in some issue tracker or wiki. I have done
>> exactly the same for PHP [1]
On Saturday 02 September 2006 07:14, David Fetter wrote:
> On Fri, Sep 01, 2006 at 09:46:02PM -0400, Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > Bruce Momjian wrote:
> > > > It pulls my a mailbox file I use, and it does instant updates as
> > > > soon as I change it. It is a URL. Why d
Peter Eisentraut wrote:
> > Not sure. I don't think the shell command and the SQL command have
> > to provide the same feedback. I don't think createuser does. Does
> > vacuumdb?
>
> Both createuser and vacuumdb provide the same feedback as the
> corresponding SQL commands.
>
> The more I thi
Martijn van Oosterhout wrote:
> I remember something about setting up a wiki for a todo list and pie
> in the sky list. I thought it had promise, but until the wiki is
> there we won't know...
I think the wiki is the prerequisite for many ideas about alternative
tracking and documentation mechani
> Not sure. I don't think the shell command and the SQL command have
> to provide the same feedback. I don't think createuser does. Does
> vacuumdb?
Both createuser and vacuumdb provide the same feedback as the
corresponding SQL commands.
The more I think about it, the patch that just went in
Simon Riggs wrote:
> On Mon, 2006-08-07 at 11:37 -0400, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > If we are in standby mode, then rather than ending recovery we go into a
> > > wait loop. We poll for the next file, then sleep for 1000 ms, then poll
> > > again. When a file a
On Sat, Sep 02, 2006 at 09:00:35AM +0200, Lukas Kahwe Smith wrote:
> Actually I should add that I went ahead and created the PHP todo list on
> my own, without any official blessing and one by one internals developer
> have joined. Now its actively used in the entire release process.
That is the
Tom, should I apply this patch now? Are you still considering other
options for this?
---
Bruce Momjian wrote:
>
> Tom, I ran your tests with fsync off (as you did), and saw numbers
> bouncing between 400-700 tps without m
1 - 100 of 105 matches
Mail list logo
