Andrew Dunstan wrote:
It would make the process more transparent, which is something several
people have expressed a desire for.
Yes, the processes seems to work by having two of the most important
people waste time on getting information anyone else could collect, or
that the developer
Lukas Kahwe Smith wrote:
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] (though there are rarely specs
Bruce Momjian wrote:
Suppress some NOTICE messages from REINDEX command.
This actually suppresses NOTICE messages in the reindexdb shell command.
Shouldn't those two behave the same, though?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
On Fri, Sep 01, 2006 at 10:13:07PM -0400, Jonah H. Harris wrote:
On 9/1/06, Bruce Momjian [EMAIL PROTECTED] wrote:
I pummelled Jonah over the recursive query patch.
He did. Trust me on this... think I still have some bruises too :)
That wasn't productive. Getting it out in public that your
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 do people care where it
is?
The complaint has been that not enough
Peter Eisentraut wrote:
Bruce Momjian wrote:
Suppress some NOTICE messages from REINDEX command.
This actually suppresses NOTICE messages in the reindexdb shell command.
Shouldn't those two behave the same, though?
Not sure. I don't think the shell command and the SQL command have to
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 my
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
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 arrives we
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
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
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 think about
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 do people care
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] (though
[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?
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:
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 thought
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 this patch was
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 commit it
and
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 server_version
Ü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.
There
-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
remarkable
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 author
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
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
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 pull
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 it
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 being
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 like
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, though, if
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.
If this sort
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, we had a lot of
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 items done in
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
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
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
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 change it. It is
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
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
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
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
review
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
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
-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 least a
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
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
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
Ü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
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
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
questions we should be asking
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 bad.
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
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
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 arguments
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
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 were being
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...
I think the
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 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:
:
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 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.
I
On 2/9/06 20:16, Martijn van Oosterhout kleptog@svana.org 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
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
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'm not in favor
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
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 with this,
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 of course
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 know if
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
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
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:todo topic
would be a good idea for detailed info on todo
On Fri, Sep 01, 2006 at 10:18:37AM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org 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
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 the
Sounds reasonable to me.
Regards, Dave
-Original Message-
From: Martijn van Oosterhout kleptog@svana.org
To: Dave Page dpage@vale-housing.co.uk
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,
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
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.
--
Bruce
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 to
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 should
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
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
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 determine if the
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 partition
[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
---(end
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
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)---
TIP
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
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
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
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
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? Now I see
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=agoutidt=2006-09-03%2002:15:01
for example
cheers
andrew
---(end of broadcast)---
TIP
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 doesn't
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=agoutidt=2006-09-03%2002:15:01
for example
It is the LIMIT/OFFSET patch changes to gram.y. I am looking at
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 for this
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.
There is *no*
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
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 care
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:
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 it pretty
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 OP means
1 - 100 of 105 matches
Mail list logo
