BUG #14148: postgres does not support GST timezone

ziyun.wang@ericsson.com writes:

got error:
ERROR: invalid input syntax for type timestamp with time zone: "Wed May 18
09:40:25 GST 2016"

You can adjust the set of zone abbreviations Postgres recognizes:
http://www.postgresql.org/docs/9.3/static/datetime-config-files.html

GST isn't in the default set because there are multiple possible meanings
according to the IANA timezone database.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On 5/18/2016 9:36 AM, ziyun.wang@ericsson.com wrote:

got error:
ERROR: invalid input syntax for type timestamp with time zone: "Wed May 18
09:40:25 GST 2016"

is that Gulf Standard Time, or South Georgia Time, or Guam Standard
Time, or what?

--
john r pierce, recycling bits in santa cruz

Hi John

GST is Gulf Standard Time

It is also defined in /usr/pgsql-9.3/share/timezonesets/Asia.txt

GST 14400 # Gulf Standard Time
# (Asia/Dubai)
# (Asia/Muscat)

Thanks
Best Regards
Audrey

From: John R Pierce [mailto:pierce@hogranch.com]
Sent: May-18-16 1:32 PM
To: Ziyun Audrey Wang; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #14148: postgres does not support GST timezone

On 5/18/2016 9:36 AM, ziyun.wang@ericsson.com<mailto:ziyun.wang@ericsson.com> wrote:

got error:

ERROR: invalid input syntax for type timestamp with time zone: "Wed May 18

09:40:25 GST 2016"

is that Gulf Standard Time, or South Georgia Time, or Guam Standard Time, or what?

--

john r pierce, recycling bits in santa cruz

Hi Tom

Thanks for the info.

By adding the GST definition it works now.

Thanks!
Best Regards
Audrey

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: May-18-16 1:24 PM
To: Ziyun Audrey Wang
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #14148: postgres does not support GST timezone

ziyun.wang@ericsson.com writes:

got error:
ERROR: invalid input syntax for type timestamp with time zone: "Wed
May 18
09:40:25 GST 2016"

You can adjust the set of zone abbreviations Postgres recognizes:
http://www.postgresql.org/docs/9.3/static/datetime-config-files.html

GST isn't in the default set because there are multiple possible meanings according to the IANA timezone database.

regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Hi,
I create a table, and then i want to add oid column, but only can use "set with oids", not use "set (oids = true)"
while create table support both. Is this a problem?

Here is is my testcase, thank you.
postgres=# create table x(a int) with(oids = false);
CREATE TABLE
postgres=# alter table x set(fillfactor = 90);
ALTER TABLE
postgres=# alter table x set (oids = true);
ERROR: unrecognized parameter "oids"
postgres=#
postgres=# alter table x set with oids;
ALTER TABLE
postgres=#

On Thu, May 19, 2016 at 2:47 AM, 自己 <zoulx1982@163.com> wrote:

Hi,
I create a table, and then i want to add oid column, but only can use
"set with oids", not use "set (oids = true)"
while create table support both. Is this a problem?

Here is is my testcase, thank you.
postgres=# create table x(a int) with(oids = false);
CREATE TABLE
postgres=# alter table x set(fillfactor = 90);
ALTER TABLE
postgres=# alter table x set (oids = true);
ERROR: unrecognized parameter "oids"
postgres=#
postgres=# alter table x set with oids;
ALTER TABLE
postgres=#

​Not according to the documentation.

http://www.postgresql.org/docs/current/static/sql-altertable.html

The specific difference you are encountering, is that the "SET ( ... )"
syntax is strictly limited to storage parameters. The presence or absence
of OIDs is not considered a storage parameter.

ALTER TABLE:
SET WITH OIDS
SET WITHOUT OIDS
​SET ( storage_parameter = value [, ... ] )

CREATE TABLE:
[ WITH ( storage_parameter [= value] [, ... ] ) | WITH OIDS | WITHOUT OIDS ]

While this may not be an example of consistency it is correctly documented
and fails quickly when done incorrectly. It doesn't seem worth improving
simply for the sake of consistency - and I suspect that we our choice of
syntax is largely or completely guided by the SQL standard.

David J.