From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Sachin Kotwal <kotsachin(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Seems bug in postgres_fdw? |
Date: | 2017-02-27 15:10:38 |
Message-ID: | 23561.1488208238@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Sachin Kotwal <kotsachin(at)gmail(dot)com> writes:
> Here , Why postgresql takes different time when remote table and foreign
> table have different definition for timestamp column?
I believe postgres_fdw sets the timezone in its remote session to UTC
for predictability of results. Your table definition is really at fault
for being dependent on what the session timezone is.
Personally I'd make the ins_ts column be timestamp with time zone, but
if you really don't want to do that, you could consider making the default
expression be "current_timestamp AT TIME ZONE 'something'" to force the
rotated value to be in a particular zone.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2017-02-27 22:58:45 | Re: BUG #14543: libpq fails with group readable ssl keys |
Previous Message | Tom Lane | 2017-02-27 14:58:15 | Re: BUG #14570: Validation error |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2017-02-27 15:20:47 | Re: gitlab post-mortem: pg_basebackup waiting for checkpoint |
Previous Message | Andres Freund | 2017-02-27 15:07:28 | Re: PATCH: two slab-like memory allocators |