From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Default to TIMESTAMP WITH TIME ZONE? |
Date: | 2021-08-13 05:14:56 |
Message-ID: | CAM-w4HOwEVCNnvvJOE-n96=YTkZcvZXfhd=CbZGgUiU9C9bBdw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I think having a GUC to change to a different set of semantics is not workable.
However that doesn't mean we can't do anything. We could have a GUC
that just disables allowing creating columns of type timestamp without
tz. That could print an error with a hint suggesting you can change
the variable if you really want to allow them.
I still would hesitate to make it the default but admins could set it
to help their developers.
You could maybe imagine a set of parameters to disable various options
that can be seen as undesirable features that sites may not want their
developers accidentally introducing.
That said, even disabling a feature is a semantic change. Consider for
example an extension that did make use of some feature. To be portable
and reliable it would have to start with a block of temporary GUC
settings to ensure it worked properly on user databases where various
settings may be in place. But that's a lot easier to manage than
subtle behavioural changes.
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2021-08-13 06:09:49 | Re: Next Steps with Hash Indexes |
Previous Message | David Rowley | 2021-08-13 04:50:50 | Re: Bug in huge simplehash |