Hi,
I'm using a domain to specialize the built in TIMEZONE WITH TIME ZONE type. I
want to sanity check this approach before continuing to use this.
I want to prevent timestamps with non-UTC offsets from getting inserted into
the database. Having a UTC-only database at the schema level means no
Sorry about the bug in the subject: the data type is TIMESTAMP WITH TIME ZONE,
not TIMEZONE WITH TIME ZONE
> On 10 May 2018, at 09:03, Ben Hood wrote:
>
> Hi,
>
> I'm using a domain to specialize the built in TIMEZONE WITH TIME ZONE type. I
> want to sanity che
> On 10 May 2018, at 09:59, Francisco Olarte wrote:
>
> On Thu, May 10, 2018 at 10:03 AM, Ben Hood wrote:
> ...
>> Am I missing the point of how Postgres stores TIMEZONE WITH TIME ZONE
>> internally?
>
> After reading in the follow up TIMEZONE is a ty
> On 10 May 2018, at 11:36, Karsten Hilbert wrote:
>
> On Thu, May 10, 2018 at 11:19:36AM +0100, Ben Hood wrote:
>
> I dare say it is one of PG's strengths' to be usable as a
> "linter”.
Interesting that you share this view, because after thinking about
> On 10 May 2018, at 14:41, Adrian Klaver wrote:
>> OK, so by using TIMESTAMP WITH TIME ZONE, you force all apps to submit
>> timezone qualified timestamps in what language they are written in.
>
> Not really:
>
> https://www.postgresql.org/docs/10/static/datatype-datetime.html
>
> "For times
> On 10 May 2018, at 15:12, Vick Khera wrote:
>
> On Thu, May 10, 2018 at 7:31 AM, Ben Hood <mailto:b...@relops.com>> wrote:
> Or are we saying that domains are one way of achieving the timestamp hygiene,
> but equally, you can get the same result as described above
> On 10 May 2018, at 15:17, Karsten Hilbert wrote:
>
>> Not really:
>>
>> https://www.postgresql.org/docs/10/static/datatype-datetime.html
>>
>> "For timestamp with time zone, the internally stored value is always in UTC
>> (Universal Coordinated Time, traditionally known as Greenwich Mean Ti
> On 10 May 2018, at 15:33, Tom Lane wrote:
>
> Ben Hood writes:
>> So the question is not how does the timestamp get stored, rather, is it an
>> anti-pattern to use Postgres as a linter for apps that forget to use UTC
>> exclusively?
>
> Well, usi
> On 10 May 2018, at 18:29, Adrian Klaver wrote:
>
> Per my previous post a timestamp with timezone is going to be stored as UTC,
> so there is no ambiguity there. On reflection I realized your concern maybe
> with determining the original input timezone. That information is not stored
> by
> On 10 May 2018, at 17:35, David G. Johnston
> wrote:
>
> '2018-05-10T15:23:00-07:00'::timestamptz is unambiguous
That is true. Mandating UTC is not the only way to eliminate ambiguity.
Apologies for appearing to suggest that this is case.
>
> Allowing client applications to represent
> On 10 May 2018, at 17:38, Adrian Klaver wrote:
>
> Well if you are using a timestamp with timezone field the value is always
> going to be stored as UTC. The TimeZone setting just determines the rotation
> from the input value to the stored value and the reverse. My previous point
> was j
> On 10 May 2018, at 16:33, Francisco Olarte wrote:
>
> For what you want to do I think you'll have to parse the text value,
> maybe by definig a view with a text columns and using some
> rule/trigger magic for insert / updates.
Sorry for being unclear - the solution I have in production appea
> On 10 May 2018, at 22:17, Peter J. Holzer wrote:
>
> I don't understand how this can work. As Francisco demonstrated,
> EXTRACT(TIMEZONE FROM ts) doesn't extract the time zone from the value
> ts, it reports the offset of the client's time zone.
Yes, you and Francisco are right.
If you do:
> On 10 May 2018, at 23:43, Adrian Klaver wrote:
>
> Trying to tame time and time zones is maybe quixotic, but not weird.
Quixotic is a very good description, I’d happily admit that using the UTC
domain in this way is not as pragmatic as I thought it would when I introduced
it.
> While I was
Hi,
I’m wondering what is the syntax for detaching multiple partitions in 1 ALTER
TABLE statement.
I’ve tried this:
# ALTER TABLE movement_legs DETACH PARTITION movement_legs_2019_06_20_11_15,
DETACH PARTITION movement_legs_2019_06_20_11_20;
psql: ERROR: syntax error at or near ","
LINE 1: .
15 matches
Mail list logo
