Am Mittwoch, 30. August 2006 18:01 schrieb Tom Lane:
This is the first time I've actually looked at this patch, and I am
dismayed. viewUpdate.c looks like nothing so much as a large program
with a small program struggling to get out. What is all the stuff about
handling multiple base rels?
--On Mittwoch, August 30, 2006 12:01:25 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Bernd Helmle [EMAIL PROTECTED] writes:
[ latest views patch ]
This is the first time I've actually looked at this patch, and I am
dismayed. viewUpdate.c looks like nothing so much as a large program
with a
On 8/30/06, Bruce Momjian [EMAIL PROTECTED] wrote:
I thought about this, and because we are placing two pieces of
information on the same line, it seems | is the best choice.
Good idea. It's far more readable with a pipe.
Oh. You want to pull the parameters out of that. I am thinking you
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
Have you tried your patch against the various cases that have been
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Mittwoch, 30. August 2006 18:01 schrieb Tom Lane:
This is the first time I've actually looked at this patch, and I am
dismayed. viewUpdate.c looks like nothing so much as a large program
with a small program struggling to get out.
But later SQL
Am Donnerstag, 31. August 2006 15:55 schrieb Tom Lane:
I'm unclear as to why you've got DO INSTEAD NOTHING rules in there ---
You need to have one unconditional rule if you have a bunch of
conditional ones. The system does not see through the fact that the
conditional ones cover all
Peter Eisentraut [EMAIL PROTECTED] writes:
Am Donnerstag, 31. August 2006 15:55 schrieb Tom Lane:
The proposed WITH CHECK OPTION implementation is unworkable for exactly
this reason --- it will give the wrong answers in the presence of
volatile functions such as nextval().
I'm not sure why
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
OK, here is a much nicer patch. The fix is to do no rounding, but to
find the number of days before applying the factor adjustment.
You have forgotten the problem of the factor not being exactly
representable (eg, things like '10
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
Have you tried your patch against the various
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
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 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
15 matches
Mail list logo
