Обсуждение: BUG #14148: postgres does not support GST timezone

VGhlIGZvbGxvd2luZyBidWcgaGFzIGJlZW4gbG9nZ2VkIG9uIHRoZSB3ZWJz
aXRlOgoKQnVnIHJlZmVyZW5jZTogICAgICAxNDE0OApMb2dnZWQgYnk6ICAg
ICAgICAgIHppeXVuIHdhbmcKRW1haWwgYWRkcmVzczogICAgICB6aXl1bi53
YW5nQGVyaWNzc29uLmNvbQpQb3N0Z3JlU1FMIHZlcnNpb246IDkuMy4xMwpP
cGVyYXRpbmcgc3lzdGVtOiAgIHJlZGhhdCA2LjcKRGVzY3JpcHRpb246ICAg
ICAgICAKCmdvdCBlcnJvcjoNCkVSUk9SOiAgaW52YWxpZCBpbnB1dCBzeW50
YXggZm9yIHR5cGUgdGltZXN0YW1wIHdpdGggdGltZSB6b25lOiAiV2VkIE1h
eSAxOAowOTo0MDoyNSBHU1QgMjAxNiIKCg==

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

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

SGkgSm9obg0KDQpHU1QgaXMgR3VsZiBTdGFuZGFyZCBUaW1lDQoNCkl0IGlzIGFsc28gZGVmaW5l
ZCBpbiAvdXNyL3Bnc3FsLTkuMy9zaGFyZS90aW1lem9uZXNldHMvQXNpYS50eHQNCg0KR1NUICAg
ICAxNDQwMCAgICAjIEd1bGYgU3RhbmRhcmQgVGltZQ0KICAgICAgICAgICAgICAgICAjICAgICAo
QXNpYS9EdWJhaSkNCiAgICAgICAgICAgICAgICAgIyAgICAgKEFzaWEvTXVzY2F0KQ0KDQpUaGFu
a3MNCkJlc3QgUmVnYXJkcw0KQXVkcmV5DQoNCg0KDQpGcm9tOiBKb2huIFIgUGllcmNlIFttYWls
dG86cGllcmNlQGhvZ3JhbmNoLmNvbV0NClNlbnQ6IE1heS0xOC0xNiAxOjMyIFBNDQpUbzogWml5
dW4gQXVkcmV5IFdhbmc7IHBnc3FsLWJ1Z3NAcG9zdGdyZXNxbC5vcmcNClN1YmplY3Q6IFJlOiBb
QlVHU10gQlVHICMxNDE0ODogcG9zdGdyZXMgZG9lcyBub3Qgc3VwcG9ydCBHU1QgdGltZXpvbmUN
Cg0KT24gNS8xOC8yMDE2IDk6MzYgQU0sIHppeXVuLndhbmdAZXJpY3Nzb24uY29tPG1haWx0bzp6
aXl1bi53YW5nQGVyaWNzc29uLmNvbT4gd3JvdGU6DQoNCmdvdCBlcnJvcjoNCg0KRVJST1I6ICBp
bnZhbGlkIGlucHV0IHN5bnRheCBmb3IgdHlwZSB0aW1lc3RhbXAgd2l0aCB0aW1lIHpvbmU6ICJX
ZWQgTWF5IDE4DQoNCjA5OjQwOjI1IEdTVCAyMDE2Ig0KDQoNCmlzIHRoYXQgR3VsZiBTdGFuZGFy
ZCBUaW1lLCBvciBTb3V0aCBHZW9yZ2lhIFRpbWUsIG9yIEd1YW0gU3RhbmRhcmQgVGltZSwgb3Ig
d2hhdD8NCg0KDQoNCi0tDQoNCmpvaG4gciBwaWVyY2UsIHJlY3ljbGluZyBiaXRzIGluIHNhbnRh
IGNydXoNCg==

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]=20
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=20
> 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 a=
ccording to the IANA timezone database.

            regards, tom lane

On Thu, May 19, 2016 at 2:47 AM, =E8=87=AA=E5=B7=B1 <zoulx1982@163.com> wro=
te:

> Hi,
>     I create a table, and then i want to add oid column, but only can use
> "set with oids", not use "set (oids =3D true)"
>     while create table support both. Is this a problem?
>
>     Here is is my testcase, thank you.
> postgres=3D# create table x(a int) with(oids =3D false);
> CREATE TABLE
> postgres=3D# alter table x set(fillfactor =3D 90);
> ALTER TABLE
> postgres=3D# alter table x set (oids =3D true);
> ERROR:  unrecognized parameter "oids"
> postgres=3D#
> postgres=3D# alter table x set with oids;
> ALTER TABLE
> postgres=3D#
>

=E2=80=8BNot 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
=E2=80=8BSET ( storage_parameter =3D value [, ... ] )

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

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.