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 s
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 yo
Guillaume Smet wrote:
> 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 par
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 b
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 l
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 cov
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 s
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 days' * 0.1 not givin
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 li
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 t
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
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 intro
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
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-dateti
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 u
Hi folks
Here's a first cut of the enums patch for feedback when people have
time. It follows an anyenum pseudo-type approach as foreseen by
Nostradamus in one of the original threads.
(http://archives.postgresql.org/pgsql-hackers/2005-11/msg00457.php).
That made the patch a little more intrus
19 matches
Mail list logo
