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. See:
On Sep 1, 2006, at 5:05 , Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Well, the patch only multiplies by 30, so the interval would have to
span +5 million years to overflow. I don't see any reason to add
rounding until we get an actual query that needs it
Magnus Hagander [EMAIL PROTECTED] writes:
The manual says:
GRANT role [, ...]
TO { username | GROUP groupname | PUBLIC } [, ...] [ WITH ADMIN
OPTION ]
It doesn't say that anymore:
http://archives.postgresql.org/pgsql-committers/2006-08/msg00034.php
Perhaps we ought to start thinking
Michael Glaesemann [EMAIL PROTECTED] writes:
I came across some behavior that seems counterintuitive to me:
test=# select '1.5 mon'::interval;
interval
-
1 mon 360:00:00
(1 row)
With the time/day/month interval struct introduced in 8.1, I'd expect
this to return '1
On Sep 1, 2006, at 9:12 , Tom Lane wrote:
Michael Glaesemann [EMAIL PROTECTED] writes:
I came across some behavior that seems counterintuitive to me:
test=# select '1.5 mon'::interval;
interval
-
1 mon 360:00:00
(1 row)
With the time/day/month interval struct
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 with the problem?
I'll check on this tonight.
I was just trying (unsuccessfully so far) to replicate Csaba Nagy's
report of a strange failure with temp table creation. I made use
of pgbench's recent improvements to be able to push random scripts
at a collection of backends:
$ cat ttscript.sql
create temp table foo (f1 int);
drop table foo;
Bruce Momjian [EMAIL PROTECTED] writes:
I am unclear about this report. The patch was not meant to fix every
interval issue, but merely to improve multiplication and division
computations. Does it do that?
According to Michael's last report, your patch fails under
--enable-integer-datetimes.
I am unclear about this report. The patch was not meant to fix every
interval issue, but merely to improve multiplication and division
computations. Does it do that? I think the 23:60 is a time rounding
issue that isn't covered in this patch. I am not against fixing it, but
does the submitted
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
I am unclear about this report. The patch was not meant to fix every
interval issue, but merely to improve multiplication and division
computations. Does it do that?
According to Michael's last report, your patch fails under
[ hijacking this thread over to where the developers hang out ]
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
It's pointless to suppose that individual developers would really be
answerable to any project-wide management, since that's not who they're
paid by. So I tend to think
On 8/31/06, Tom Lane [EMAIL PROTECTED] wrote:
I was just trying (unsuccessfully so far) to replicate Csaba Nagy's
report of a strange failure with temp table creation. I made use
of pgbench's recent improvements to be able to push random scripts
at a collection of backends:
$ cat ttscript.sql
On Aug 31, 2006, at 8:47 PM, Tom Lane wrote:
[ hijacking this thread over to where the developers hang out ]
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
It's pointless to suppose that individual developers would really be
answerable to any project-wide management, since that's
Merlin Moncure [EMAIL PROTECTED] writes:
On 8/31/06, Tom Lane [EMAIL PROTECTED] wrote:
What I found surprising is that I get numbers like 430 tps from HEAD
and 220 tps from REL8_1_STABLE. This test case is of course not about
performance, but I'm not quite sure what we changed that would
we will know whether this is a great thing we should continue, or we
should stick to our traditional laissez-faire style of project
management. I figure that even if it really sucks, it wouldn't kill us
to try it for one release cycle --- at the very worst, we'd make up lost
time in future by no
Tom,
I propose a modest experiment: for the 8.3 development cycle, let's try
to agree (in the next month or so) on a roadmap of what major features
should be in 8.3 and who will make each one happen.
Well, I think the what is more important that the who -- we can switch whos
if that's what
101 - 116 of 116 matches
Mail list logo
