Re: Default to TIMESTAMP WITH TIME ZONE? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Default to TIMESTAMP WITH TIME ZONE?
Date
Msg-id 77174.1628874448@sss.pgh.pa.us
Whole thread Raw
In response to Re: Default to TIMESTAMP WITH TIME ZONE?  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Default to TIMESTAMP WITH TIME ZONE?  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Default to TIMESTAMP WITH TIME ZONE?  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Fri, Aug 13, 2021 at 9:28 AM Simon Riggs <simon.riggs@enterprisedb.com>
> wrote:
>> The only hope is to eventually change the default, so probably
>> the best thing is to apply pressure via the SQL Std process.

> Then there is no hope because this makes the situation worse.

Agreed; the points I made upthread are just as valid if the change
is made in the standard.  But I'd be astonished if the SQL committee
would consider such a change anyway.

The one thing I could potentially see us doing is more strongly
encouraging the use of the names "timestamp" and "timestamptz",
up to and including changing what format_type() et al. put out.
Yeah, "timestamptz" is not standard, but so what?  At least it's
not actually *contrary* to the standard, as the original proposal
here is.  (Also, while I hate to bring it up in this context,
our timestamptz data type is not really compatible with the spec
in the first place, so that a case could be made that this behavior
is more honest/spec-compatible than what we do today.)

If you wanted to be even more in people's faces about it, you
could print the type names as "timestamptz" and "timestamp
without time zone".

            regards, tom lane



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: Default to TIMESTAMP WITH TIME ZONE?
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Native spinlock support on RISC-V