Re: Default to TIMESTAMP WITH TIME ZONE?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Default to TIMESTAMP WITH TIME ZONE?
Дата
Msg-id 77174.1628874448@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Default to TIMESTAMP WITH TIME ZONE?  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: Default to TIMESTAMP WITH TIME ZONE?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] Native spinlock support on RISC-V