Re: [HACKERS] pgsql: Remove internal uses of CTimeZone/HasCTZSet.

2013-11-05 Thread Robert Haas
On Mon, Nov 4, 2013 at 8:17 PM, Noah Misch n...@leadboat.com wrote: On Mon, Nov 04, 2013 at 02:34:02PM -0500, Tom Lane wrote: Noah Misch n...@leadboat.com writes: On Fri, Nov 01, 2013 at 04:51:34PM +, Tom Lane wrote: Remove internal uses of CTimeZone/HasCTZSet. This changed

Re: [HACKERS] pgsql: Remove internal uses of CTimeZone/HasCTZSet.

2013-11-05 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Mon, Nov 4, 2013 at 8:17 PM, Noah Misch n...@leadboat.com wrote: I was prepared to suppose that no substantial clientele relies on the to_char() TZ format code expanding to blank, the other behavior that changed with this patch. It's more of a

Re: [HACKERS] pgsql: Remove internal uses of CTimeZone/HasCTZSet.

2013-11-04 Thread Noah Misch
On Fri, Nov 01, 2013 at 04:51:34PM +, Tom Lane wrote: Remove internal uses of CTimeZone/HasCTZSet. The only remaining places where we actually look at CTimeZone/HasCTZSet are abstime2tm() and timestamp2tm(). Now that session_timezone is always valid, we can remove these special cases.

Re: [HACKERS] pgsql: Remove internal uses of CTimeZone/HasCTZSet.

2013-11-04 Thread Tom Lane
Noah Misch n...@leadboat.com writes: On Fri, Nov 01, 2013 at 04:51:34PM +, Tom Lane wrote: Remove internal uses of CTimeZone/HasCTZSet. This changed EncodeDateTime() output for USE_SQL_DATES and USE_GERMAN_DATES styles, because it inserts a space before tzn but does not insert a space

Re: [HACKERS] pgsql: Remove internal uses of CTimeZone/HasCTZSet.

2013-11-04 Thread Noah Misch
On Mon, Nov 04, 2013 at 02:34:02PM -0500, Tom Lane wrote: Noah Misch n...@leadboat.com writes: On Fri, Nov 01, 2013 at 04:51:34PM +, Tom Lane wrote: Remove internal uses of CTimeZone/HasCTZSet. This changed EncodeDateTime() output for USE_SQL_DATES and USE_GERMAN_DATES styles,