Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> The reason the "char" arithmetic operators are dangerous is that they are
>> the only ones of those names in the STRING type category.
> What would happen if "char" were just removed from the STRING type category?
Wh
Tom Lane <[EMAIL PROTECTED]> writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> What I'm inclined to do with these is change pg_proc.h but not force
> >> an initdb. Does anyone want to argue for an initdb to force it to be
> >> fixed in 8.0? We've lived with the wron
Not that my 2c is worth 1c, but I second this. I'd rather initdb now
than get bitten by some catalog difference when I move my DB into
production. :)
--miker
On Sat, 02 Oct 2004 14:22:50 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
[...]
>
> > I'd prefer if all users of 8.0 were guaranteed to hav
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: 02 October 2004 19:23
> To: Peter Eisentraut
> Cc: Bruno Wolff III; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Mislabeled timestamp functions (was
> Re: [SQ
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What I'm inclined to do with these is change pg_proc.h but not force
>> an initdb. Does anyone want to argue for an initdb to force it to be
>> fixed in 8.0? We've lived with the wrong labelings for some time now
>> without noticin
Tom Lane wrote:
> What I'm inclined to do with these is change pg_proc.h but not force
> an initdb. Does anyone want to argue for an initdb to force it to be
> fixed in 8.0? We've lived with the wrong labelings for some time now
> without noticing, so it doesn't seem like a serious enough bug to
On Fri, Oct 01, 2004 at 18:53:03 -0400,
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> What I'm inclined to do with these is change pg_proc.h but not force an
> initdb. Does anyone want to argue for an initdb to force it to be fixed
> in 8.0? We've lived with the wrong labelings for some time now wit
I wrote:
> Looking at this, I realize that date_trunc() is mismarked: the
> timestamptz variant is strongly dependent on the timezone setting
> and so should be STABLE not IMMUTABLE. Ooops.
On looking more closely, I think that all of these functions are
mislabeled:
