On Sep 4, 2006, at 12:44 , Tom Lane wrote:
OK, so if everyone is leaning to #3, the name game remains to be
played.
Do we all agree on this:
"x @> y" means "x contains y"
"x @< y" means "x is contained in y"
Are we all prepared to sign a solemn oath to commit hara-kiri if we
Andrew Dunstan wrote:
I spent months on a working party on these and similar issues a few
years back, in a commercial setting. One of the big issues is when you
start tracking something. Bugs are a pretty simple case. Features are
much harder to handle. Someone comes up with an idea. There is
Tom Lane wrote:
AFAICS the bottom line here is that we need some intelligent filtering.
In the short run I doubt that we can have that except through human
gruntwork to filter the mail traffic and update a tracker database.
Maybe after we see such a system in operation for awhile, we can start
t
On Mon, September 4, 2006 03:56, Gregory Stark wrote:
> Thanks, that cleared things up enormously. I'm trying to figure how it
> would
> react to some of the queries I've written in the past. In particular I'm
> thinking of queries like
>
> WHERE (? OR category = ?)
> AND (? OR cost < ?)
> AND
On Sun, September 3, 2006 23:52, Tom Lane wrote:
> What exactly do you mean by "optimize away a parameter"? The way you
> described the mechanism, there are no parameters that are "optimized
> away", you've merely adjusted selectivity predictions using some assumed
> values.
I'm using "optimized
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> For the record, the error I'm getting is
> Makefile:3: ../../../src/Makefile.global: No such file or directory
> make: *** No rule to make target `../../../src/Makefile.global'. Stop.
>From which Makefile exactly? Sounds like a pretty vanilla VPAT
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> There's a lot of duplicate code in ecpg.
No kidding :-(. The parser is bad enough but the datatype library is
an order of magnitude worse. I don't have a great solution at hand
though. The backend utils/adt/ code gets to rely on the backend's
er
[Removing -patches]
On Sep 4, 2006, at 10:33 , Tom Lane wrote:
* AFAICT the ecpg regression tests are not affected by this change.
Yeah, it doesn't look like there's any tests for interval at all. I
suppose there should be. There's a lot of duplicate code in ecpg. Is
there any way to pull
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> 3. Leave the existing op names as-is in core and contrib, but consider
>>>them deprecated and add new ops with consistently-chosen names.
>>>(The new ops introduced by GIN should only exist with the new names.)
> You're right
Martijn van Oosterhout said:
> Ok, it looks like pages can be arranged hierarchically.
Well, a prefix like "Todo:" is not the incantation one needs to use to
arrange pages in hierarchies. You probably want "/" to indicate a subpage:
i.e. "Parent/Child". See
http://meta.wikimedia.org/wiki/Help:Link
This is not that far different from the premise upon which you built
the buildfarm: that there were people out there able to provide machine
resources and a certain amount of admin time. The resources this
project requires are not those exactly, but why shouldn't we expect
that some people will
Hello,
O.k. I have installed the stable bugzilla at:
http://pgbugs.commandprompt.com/
I would expect that this domain would change to:
http://bugs.postgresql.org/ or something
It is backed to a PostgreSQL 8.1 database and anyone can now create
accounts.
Now what I need.
I need a couple of
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> Oh, lots of grunt work. I can see that working, but at a high cost.
> I doubt it. Let's just start with bugs, since that's the easy case
> anyway. Our real volume is pretty low, so the cost of maintaining it
> should not be hi
Andrew Dunstan wrote:
Bruce Momjian wrote:
Oh, lots of grunt work. I can see that working, but at a high cost.
I doubt it. Let's just start with bugs, since that's the easy case
anyway. Our real volume is pretty low, so the cost of maintaining it
should not be high. I am assuming we
The *big* steps are moving email and CVS.
*big* but quite easy :) As long as we have an mbox file from the slony
lists, we can import easily into pgfoundry.
CVS is just an rsync ;)
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564
The world rejoiced as [EMAIL PROTECTED] ("Joshua D. Drake") wrote:
> 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.
Bruce Momjian wrote:
Oh, lots of grunt work. I can see that working, but at a high cost.
I doubt it. Let's just start with bugs, since that's the easy case
anyway. Our real volume is pretty low, so the cost of maintaining it
should not be high. I am assuming we would not be including
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Oh, so the bug is tracked by being part of the email reply list. That
> > is a good idea. Now, how does that get assigned for non-bugs, like
> > patches? Does any email sent to the lists that doesn't already have a
> > bug number ge
Tom Lane wrote:
AFAICS the bottom line here is that we need some intelligent filtering.
In the short run I doubt that we can have that except through human
gruntwork to filter the mail traffic and update a tracker database.
Maybe after we see such a system in operation for awhile, we can start
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Anyway, let me reiterate: bz has at least the start of an email reply
> facility, and making that work if it doesn't already should not be
> beyond us.
I agree that starting from scratch seems like a good way to waste a
lot of time. I don't have a pr
Bruce Momjian wrote:
Oh, so the bug is tracked by being part of the email reply list. That
is a good idea. Now, how does that get assigned for non-bugs, like
patches? Does any email sent to the lists that doesn't already have a
bug number get one? That might be really valuable.
It wou
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Oh, so the bug is tracked by being part of the email reply list. That
> is a good idea. Now, how does that get assigned for non-bugs, like
> patches? Does any email sent to the lists that doesn't already have a
> bug number get one? That might be real
[EMAIL PROTECTED] (Tom Lane) wrote:
> I agree with planning to arrive at state #4 after a transitional release
> or three, but to do it now with no warning will simply bring us visits
> from angry pitchfork-bearing villagers...
But then we can send out Trogdor...
Trogdor!
Trogdor!
Burninating th
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I do
>> PATH=/usr/local/autoconf-2.53/bin:$PATH autoconf
>> when I need to update back-branch configure scripts.
> Ah! Thanks! What had failed for me was just running with
> /path/to/old/autoconf - this one works however. Strang
Tom Lane wrote:
> Michael Glaesemann <[EMAIL PROTECTED]> writes:
> > On Sep 4, 2006, at 9:41 , Tom Lane wrote:
> >> This patch fails to apply --- looks like whitespace got mangled in
> >> transit. Please resend as an attachment.
>
> > Please let me know if you have any problems with this one.
>
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > As for remarks about old school unix hackers not liking web interfaces,
> > I think Tom's recent remarks relating to the 21st century were more than
> > apposite.
>
> I don't see a big problem with using a web interface to search f
Gregory Stark wrote:
>
> Martijn van Oosterhout writes:
>
> > I assume other bug trackers have a similar feature...
>
> Sadly no. That's precisely why I was pushing debbugs so hard earlier.
Oh. That is bad.
> The weakest of them will send a content-free email saying *something* happened
> t
Satoshi Nagayasu <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> pgstatindex.c: In function 'bt_page_items':
>> pgstatindex.c:564: warning: format '%d' expects type 'int', but argument 4
>> has type 'long unsigned int'
> I guess my '%d' should be '%zd', right?
No, that sounds even less portable
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Sun, Sep 03, 2006 at 03:40:40PM -0400, Bruce Momjian wrote:
> > This is also an interesting example for a tracker. If we had one, all
> > discussion on the patch would be in one place, but I am thinking that
> > would require all p
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Without a reply from Peter, I have to assume the patch is valid.
>
> To make it more explicit: I think the patch is stupid, but if someone
> wants to review it, go ahead. But I am not comfortable with the "if no
> one objects, I'll just commit
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Peter Eisentraut wrote:
Ideally, we would get Python to tell us the right location, because "use lib64
if it exists" isn't the right solution.
Is this fixed somewhere post 7.4?
Yes, but it was never backported.
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> The two attached patches fix contrib/pgstattuple.
Good, applied. I made some additional changes to get install/uninstall/
reinstall to work cleanly after the latest additions, and to get it to
compile without warnings on a 64-bit Fedora machine. (It
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I see that older back branches are still using version 2.53 of autoconf,
rather than the 2.59 branch we have updated to for 8.1 and beyond. Does
that mean I need to install version 2.53 if I want to update the config
on those bran
Tom Lane wrote:
You mentioned being unable to get the ecpg tests to run on your
machine. I'm sure Michael and Joachim would like the details. The
ecpg regression tests are pretty new and some portability problems
are to be expected, but they seem to be passing on all the machines
Michael and
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> On Sep 4, 2006, at 9:41 , Tom Lane wrote:
>> This patch fails to apply --- looks like whitespace got mangled in
>> transit. Please resend as an attachment.
> Please let me know if you have any problems with this one.
Ah, that one works --- applied
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
As for remarks about old school unix hackers not liking web interfaces,
I think Tom's recent remarks relating to the 21st century were more than
apposite.
I don't see a big problem with using a web interface to search for
in
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
How about?:
4. do 1+3, i.e. flip the GIN operators to keep core consistency, but
deprecate the operators for both contrib and core. Something more
visually like set ops would be ideal.
If we're going to adopt new preferred
Mark Dilger <[EMAIL PROTECTED]> writes:
> I suggest: #4 Standardize on new names and completely drop old naming
> scheme, both in core and in contrib.
Deliberately breaking code that has always worked doesn't sound very
appetizing to me. If there were simply no good alternative to it, then
maybe
On Sep 4, 2006, at 9:41 , Tom Lane wrote:
This patch fails to apply --- looks like whitespace got mangled in
transit. Please resend as an attachment.
Please let me know if you have any problems with this one.
Michael Glaesemann
grzm seespotcode net
10interval_input_0904T0855+0900.diff
De
Tom Lane wrote:
I can see various things that we might consider doing:
1. Just flip the names of the two operators added by the GIN patch.
2. #1 plus flip the names of the various contrib operators that are
out of sync (Michael Fuhr points out that contrib/intarray is out
of step too ...
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> I realized there might be something in ecpg, and there was. I've
> updated the ecpg DecodeInterval to match. However, I haven't been
> able to get ecpg make check to work, so that part's untested.
This patch fails to apply --- looks like whitesp
On Sep 3, 2006, at 20:00 , Michael Glaesemann wrote:
On Sep 1, 2006, at 9:32 , Tom Lane wrote:
Michael Glaesemann <[EMAIL PROTECTED]> writes:
On Sep 1, 2006, at 9:12 , Tom Lane wrote:
I agree that this seems like an oversight in the original
months/days/seconds patch, rather than behavior
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
As for remarks about old school unix hackers not liking web interfaces,
I think Tom's recent remarks relating to the 21st century were more than
apposite.
I don't see a big problem with using a web interface to search for
information
Tom Lane wrote:
> gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
> -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -fpic
> -I. -I../../src/include -D_GNU_SOURCE -c -o pgstatindex.o pgstatindex.c
> pgstatindex.c: In function 'bt_page_items':
> pgstatindex.c:564
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> As for remarks about old school unix hackers not liking web interfaces,
> I think Tom's recent remarks relating to the 21st century were more than
> apposite.
I don't see a big problem with using a web interface to search for
information --- they're g
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I see that older back branches are still using version 2.53 of autoconf,
> rather than the 2.59 branch we have updated to for 8.1 and beyond. Does
> that mean I need to install version 2.53 if I want to update the config
> on those branches?
Yup. We
Andrew Dunstan wrote:
> I see that older back branches are still using version 2.53 of
> autoconf, rather than the 2.59 branch we have updated to for 8.1 and
> beyond. Does that mean I need to install version 2.53 if I want to
> update the config on those branches?
Yes.
> If so, fixing the plpyth
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> How about?:
> 4. do 1+3, i.e. flip the GIN operators to keep core consistency, but
> deprecate the operators for both contrib and core. Something more
> visually like set ops would be ideal.
If we're going to adopt new preferred names, I see no reason
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Patch applied. Thanks.
For some reason I expected this patch to correct the portability errors
and design problems identified here:
http://archives.postgresql.org/pgsql-patches/2006-07/msg00100.php
Not only has it not fixed anything, it's made things w
I also vote +1 for #3. Not only are there too many users, but simply
switching the sense of these operators will mean that code will still run,
but give incorrect answers and while it would be nice to think that all
client code has decent regression testing, this ain't the case.
If we are going to
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> As for remarks about old school unix hackers not liking web interfaces, I
> think Tom's recent remarks relating to the 21st century were more than
> apposite.
I like web interfaces well enough for the things they're good at.
Replacing e-mail is not o
Tom Lane wrote:
Awhile back I complained that while all the core geometric datatypes
use operator @ to mean "contained in" and operator ~ to mean "contains",
contrib/cube and contrib/seg switch the meanings:
http://archives.postgresql.org/pgsql-hackers/2005-06/msg01238.php
There was some follo
Gregory Stark wrote:
Martijn van Oosterhout writes:
I assume other bug trackers have a similar feature...
Sadly no. That's precisely why I was pushing debbugs so hard earlier.
The weakest of them will send a content-free email saying *something* happened
to your issue and you ha
Martijn van Oosterhout writes:
> I assume other bug trackers have a similar feature...
Sadly no. That's precisely why I was pushing debbugs so hard earlier.
The weakest of them will send a content-free email saying *something* happened
to your issue and you have to click a link to find out wh
I see that older back branches are still using version 2.53 of autoconf,
rather than the 2.59 branch we have updated to for 8.1 and beyond. Does
that mean I need to install version 2.53 if I want to update the config
on those branches? If so, fixing the plpython problem I reported
recently se
On Sat, Sep 02, 2006 at 11:46:12PM +0100, Dave Page wrote:
> Sounds reasonable to me.
Ok, I've typed some stuff in here:
http://developer.postgresql.org/index.php/Todo:Contents
http://developer.postgresql.org/index.php/Todo:Collate
Is this the kind of thing people are expecting?
Have a nice day
On Sun, Sep 03, 2006 at 03:40:40PM -0400, Bruce Momjian wrote:
> This is also an interesting example for a tracker. If we had one, all
> discussion on the patch would be in one place, but I am thinking that
> would require all posting to happen in a browser, or somehow have emails
> tagged to atta
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> Oh, sorry--I guess I haven't been too systematic about it. In the
> algorithm's current incarnation, ...
Thanks, that cleared things up enormously. I'm trying to figure how it would
react to some of the queries I've written in the past. In part
Bruce Momjian wrote:
> Without a reply from Peter, I have to assume the patch is valid.
To make it more explicit: I think the patch is stupid, but if someone
wants to review it, go ahead. But I am not comfortable with the "if no
one objects, I'll just commit it" mode that is sometimes going on.
Oleg Bartunov writes:
>>> 3. Leave the existing op names as-is in core and contrib, but consider
>>> them deprecated and add new ops with consistently-chosen names.
>>> (The new ops introduced by GIN should only exist with the new names.)
> #3 looks good to me. Too many users.
Not only that, but
bruce wrote:
> Tom Lane wrote:
> > 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
> > >
Joshua D. Drake wrote:
>
> >>> 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
Tom Lane wrote:
> 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'
Oleg Bartunov wrote:
On Sun, 3 Sep 2006, Joshua D. Drake wrote:
I can see various things that we might consider doing:
1. Just flip the names of the two operators added by the GIN patch.
2. #1 plus flip the names of the various contrib operators that are
out of sync (Michael Fuhr points
On Sun, 3 Sep 2006, Joshua D. Drake wrote:
I can see various things that we might consider doing:
1. Just flip the names of the two operators added by the GIN patch.
2. #1 plus flip the names of the various contrib operators that are
out of sync (Michael Fuhr points out that contrib/intar
I can see various things that we might consider doing:
1. Just flip the names of the two operators added by the GIN patch.
2. #1 plus flip the names of the various contrib operators that are
out of sync (Michael Fuhr points out that contrib/intarray is out
of step too ... are there other
Awhile back I complained that while all the core geometric datatypes
use operator @ to mean "contained in" and operator ~ to mean "contains",
contrib/cube and contrib/seg switch the meanings:
http://archives.postgresql.org/pgsql-hackers/2005-06/msg01238.php
There was some followup discussion gener
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> If multiple cached plans can be applied to a given call, we prefer the one
> that optimizes away the most parameters.
What exactly do you mean by "optimize away a parameter"? The way you
described the mechanism, there are no parameters that are
On Sun, September 3, 2006 23:28, Jeroen T. Vermeulen wrote:
> On Sun, September 3, 2006 21:52, Gregory Stark wrote:
>> I read that but apparently I misunderstood it since it would not have
>> been
>> doable the way I understood it. I thought you wanted the predictor bits
>> to
>> correspond to par
Tom Lane wrote:
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 f
On Sun, September 3, 2006 21:52, Gregory Stark wrote:
> I read that but apparently I misunderstood it since it would not have been
> doable the way I understood it. I thought you wanted the predictor bits to
> correspond to particular plans. If a plan was "wrong" then you marked it
> as a
> bad gu
Joshua D. Drake wrote:
> I was also thinking the domain: tracker.postgresql.org?
Certainly not for bugzilla.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please sen
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> OTOH I think we only need to store live Xids and those finished that
> wrote a WAL record; we can drop subaborted and subcommitted if they
> didn't.
While reviewing this thread, I see Alvaro already had the idea I just
came to...
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes:
> I added a subxid array to Snapshot and running subxids are gathered from
> PGPROC->subxids cache. There are two overflowed case; any of PGPROC->subxids
> are overflowed or the number of total subxids exceeds pre-allocated buffers.
> If overflowed, we c
Andrew Dunstan wrote:
Tom Lane wrote:
The buildfarm script is supposed to complain about unexpected files in
the repository --- I wonder if it is fooled by the .cvsignore entries
for these files?
Yes, we do. A patch made in July 2005 has this comment:
"ignore files listed in cvsignore f
On Sat, 2 Sep 2006, Bruce Momjian wrote:
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
Peter Eisentraut wrote:
Joshua D. Drake wrote:
http://pgbugs.commandprompt.com (still need to configure email).
Thank you for that.
I think an issue tracking system for patches and such may need to be
distinct from a bug-tracking system such as bugzilla, but let's get one
thing after anothe
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> On Sun, September 3, 2006 18:41, Gregory Stark wrote:
>
>> I'm confused, what exactly are you trying to predict? Whether each
>> parameter
>> will be some cached value? Or whether the cached plan was correct?
>
> That's described in more detail
On Sun, September 3, 2006 18:41, Gregory Stark wrote:
> I'm confused, what exactly are you trying to predict? Whether each
> parameter
> will be some cached value? Or whether the cached plan was correct?
That's described in more detail in a separate thread ("prepared statements
considered harmful
Tom Lane wrote:
> 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 s
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> For now, I'll summarize some results I got from randomized input data. I
> used very simple traces, with 11 prepared statements, each taking a
> different number of parameters (0 through 10, inclusive). All calls were
> uniformly randomized. I
On Sep 1, 2006, at 9:32 , Tom Lane wrote:
Michael Glaesemann <[EMAIL PROTECTED]> writes:
On Sep 1, 2006, at 9:12 , Tom Lane wrote:
I agree that this seems like an oversight in the original
months/days/seconds patch, rather than behavior we want to keep.
But is DecodeInterval the only place wi
I've rigged up a simple simulator for the scheme I described for detecting
pseudo-constant parameters to prepared statements. It withstands simple
tests, and it neatly picks up cases where some parameters are
pseudo-constants and others aren't--even if some of them are more "pseudo"
while others a
Joshua D. Drake wrote:
> http://pgbugs.commandprompt.com (still need to configure email).
Thank you for that.
I think an issue tracking system for patches and such may need to be
distinct from a bug-tracking system such as bugzilla, but let's get one
thing after another up.
--
Peter Eisentrau
84 matches
Mail list logo
