<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/postgresql.git, branch REL9_3_12</title>
<subtitle>git.postgresql.org: git/postgresql.git
</subtitle>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/'/>
<entry>
<title>Stamp 9.3.12.</title>
<updated>2016-03-28T20:12:29+00:00</updated>
<author>
<name>Tom Lane</name>
<email>tgl@sss.pgh.pa.us</email>
</author>
<published>2016-03-28T20:12:29+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=a3c643938166abed9a390cdbd8a5df09bfe39523'/>
<id>a3c643938166abed9a390cdbd8a5df09bfe39523</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Translation updates</title>
<updated>2016-03-28T06:50:07+00:00</updated>
<author>
<name>Peter Eisentraut</name>
<email>peter_e@gmx.net</email>
</author>
<published>2016-03-28T06:50:07+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=e0f4c9e7c5dbeec4d63da0a3dd60c6159bd3ffac'/>
<id>e0f4c9e7c5dbeec4d63da0a3dd60c6159bd3ffac</id>
<content type='text'>
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 4891e88b1972d0091e8e5cefd145600801ba58be
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 4891e88b1972d0091e8e5cefd145600801ba58be
</pre>
</div>
</content>
</entry>
<entry>
<title>Release notes for 9.5.2, 9.4.7, 9.3.12, 9.2.16, 9.1.21.</title>
<updated>2016-03-27T23:26:26+00:00</updated>
<author>
<name>Tom Lane</name>
<email>tgl@sss.pgh.pa.us</email>
</author>
<published>2016-03-27T23:26:26+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=9d050969966e9a1c1cd3f99812617f6c64f5703b'/>
<id>9d050969966e9a1c1cd3f99812617f6c64f5703b</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Change various Gin*Is* macros to return 0/1.</title>
<updated>2016-03-27T15:47:50+00:00</updated>
<author>
<name>Andres Freund</name>
<email>andres@anarazel.de</email>
</author>
<published>2016-03-27T15:47:50+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=65a8a3f9f60b174d6a614dbe96169b18cf7a5366'/>
<id>65a8a3f9f60b174d6a614dbe96169b18cf7a5366</id>
<content type='text'>
Returning the direct result of bit arithmetic, in a macro intended to be
used in a boolean manner, can be problematic if the return value is
stored in a variable of type 'bool'. If bool is implemented using C99's
_Bool, that can lead to comparison failures if the variable is then
compared again with the expression (see ginStepRight() for an example
that fails), as _Bool forces the result to be 0/1. That happens in some
configurations of newer MSVC compilers.  It's also problematic when
storing the result of such an expression in a narrower type.

Several gin macros have been declared in that style since gin's initial
commit in 8a3631f8d86.

There's a lot more macros like this, but this is the only one causing
regression test failures; and I don't want to commit and backpatch a
larger patch with lots of conflicts just before the next set of minor
releases.

Discussion: 20150811154237.GD17575@awork2.anarazel.de
Backpatch: All supported branches
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Returning the direct result of bit arithmetic, in a macro intended to be
used in a boolean manner, can be problematic if the return value is
stored in a variable of type 'bool'. If bool is implemented using C99's
_Bool, that can lead to comparison failures if the variable is then
compared again with the expression (see ginStepRight() for an example
that fails), as _Bool forces the result to be 0/1. That happens in some
configurations of newer MSVC compilers.  It's also problematic when
storing the result of such an expression in a narrower type.

Several gin macros have been declared in that style since gin's initial
commit in 8a3631f8d86.

There's a lot more macros like this, but this is the only one causing
regression test failures; and I don't want to commit and backpatch a
larger patch with lots of conflicts just before the next set of minor
releases.

Discussion: 20150811154237.GD17575@awork2.anarazel.de
Backpatch: All supported branches
</pre>
</div>
</content>
</entry>
<entry>
<title>Modernize zic's test for valid timezone abbreviations.</title>
<updated>2016-03-26T19:59:26+00:00</updated>
<author>
<name>Tom Lane</name>
<email>tgl@sss.pgh.pa.us</email>
</author>
<published>2016-03-26T19:58:44+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=8ea71fd2eaaa5e255bdd5badfd991000234cbb5a'/>
<id>8ea71fd2eaaa5e255bdd5badfd991000234cbb5a</id>
<content type='text'>
We really need to sync all of our IANA-derived timezone code with upstream,
but that's going to be a large patch and I certainly don't care to shove
such a thing into stable branches immediately before a release.  As a
stopgap, copy just the tzcode2016c logic that checks validity of timezone
abbreviations.  This prevents getting multiple "time zone abbreviation
differs from POSIX standard" bleats with tzdata 2014b and later.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We really need to sync all of our IANA-derived timezone code with upstream,
but that's going to be a large patch and I certainly don't care to shove
such a thing into stable branches immediately before a release.  As a
stopgap, copy just the tzcode2016c logic that checks validity of timezone
abbreviations.  This prevents getting multiple "time zone abbreviation
differs from POSIX standard" bleats with tzdata 2014b and later.
</pre>
</div>
</content>
</entry>
<entry>
<title>Update time zone data files to tzdata release 2016c.</title>
<updated>2016-03-25T23:03:39+00:00</updated>
<author>
<name>Tom Lane</name>
<email>tgl@sss.pgh.pa.us</email>
</author>
<published>2016-03-25T23:03:08+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=8e16592d4f56080b82ae15fea106f46ad331dc8d'/>
<id>8e16592d4f56080b82ae15fea106f46ad331dc8d</id>
<content type='text'>
DST law changes in Azerbaijan, Chile, Haiti, Palestine, and Russia (Altai,
Astrakhan, Kirov, Sakhalin, Ulyanovsk regions).  Historical corrections
for Lithuania, Moldova, Russia (Kaliningrad, Samara, Volgograd).

As of 2015b, the keepers of the IANA timezone database started to use
numeric time zone abbreviations (e.g., "+04") instead of inventing
abbreviations not found in the wild like "ASTT".  This causes our rather
old copy of zic to whine "warning: time zone abbreviation differs from
POSIX standard" several times during "make install".  This warning is
harmless according to the IANA folk, and I don't see any problems with
these abbreviations in some simple tests; but it seems like now would be
a good time to update our copy of the tzcode stuff.  I'll look into that
soon.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
DST law changes in Azerbaijan, Chile, Haiti, Palestine, and Russia (Altai,
Astrakhan, Kirov, Sakhalin, Ulyanovsk regions).  Historical corrections
for Lithuania, Moldova, Russia (Kaliningrad, Samara, Volgograd).

As of 2015b, the keepers of the IANA timezone database started to use
numeric time zone abbreviations (e.g., "+04") instead of inventing
abbreviations not found in the wild like "ASTT".  This causes our rather
old copy of zic to whine "warning: time zone abbreviation differs from
POSIX standard" several times during "make install".  This warning is
harmless according to the IANA folk, and I don't see any problems with
these abbreviations in some simple tests; but it seems like now would be
a good time to update our copy of the tzcode stuff.  I'll look into that
soon.
</pre>
</div>
</content>
</entry>
<entry>
<title>Remove dependency on psed for MSVC builds.</title>
<updated>2016-03-19T22:51:01+00:00</updated>
<author>
<name>Andrew Dunstan</name>
<email>andrew@dunslane.net</email>
</author>
<published>2016-03-19T22:36:35+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=a0adf38529d9ad3f4060f788a50ea619be21bcce'/>
<id>a0adf38529d9ad3f4060f788a50ea619be21bcce</id>
<content type='text'>
Modern Perl has removed psed from its core distribution, so it might not
be readily available on some build platforms. We therefore replace its
use with a Perl script generated by s2p, which is equivalent to the sed
script. The latter is retained for non-MSVC builds to avoid creating a
new hard dependency on Perl for non-Windows tarball builds.

Backpatch to all live branches.

Michael Paquier and me.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Modern Perl has removed psed from its core distribution, so it might not
be readily available on some build platforms. We therefore replace its
use with a Perl script generated by s2p, which is equivalent to the sed
script. The latter is retained for non-MSVC builds to avoid creating a
new hard dependency on Perl for non-Windows tarball builds.

Backpatch to all live branches.

Michael Paquier and me.
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix "pg_bench -C -M prepared".</title>
<updated>2016-03-17T03:18:07+00:00</updated>
<author>
<name>Tom Lane</name>
<email>tgl@sss.pgh.pa.us</email>
</author>
<published>2016-03-17T03:18:07+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=c02aae418527ec6f5178c68e2980e02d36090c42'/>
<id>c02aae418527ec6f5178c68e2980e02d36090c42</id>
<content type='text'>
This didn't work because when we dropped and re-established a database
connection, we did not bother to reset session-specific state such as
the statements-are-prepared flags.

The st-&gt;prepared[] array certainly needs to be flushed, and I cleared a
couple of other fields as well that couldn't possibly retain meaningful
state for a new connection.

In passing, fix some bogus comments and strange field order choices.

Per report from Robins Tharakan.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This didn't work because when we dropped and re-established a database
connection, we did not bother to reset session-specific state such as
the statements-are-prepared flags.

The st-&gt;prepared[] array certainly needs to be flushed, and I cleared a
couple of other fields as well that couldn't possibly retain meaningful
state for a new connection.

In passing, fix some bogus comments and strange field order choices.

Per report from Robins Tharakan.
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix typos in comments</title>
<updated>2016-03-15T20:57:16+00:00</updated>
<author>
<name>Alvaro Herrera</name>
<email>alvherre@alvh.no-ip.org</email>
</author>
<published>2016-03-15T20:57:16+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=cfc5357c0810ba76f50244aeb5d6890d8dd3a308'/>
<id>cfc5357c0810ba76f50244aeb5d6890d8dd3a308</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Cope if platform declares mbstowcs_l(), but not locale_t, in &lt;xlocale.h&gt;.</title>
<updated>2016-03-15T17:19:58+00:00</updated>
<author>
<name>Tom Lane</name>
<email>tgl@sss.pgh.pa.us</email>
</author>
<published>2016-03-15T17:19:58+00:00</published>
<link rel='alternate' type='text/html' href='http://trove.baserock.org/cgit/delta/postgresql.git/commit/?id=4b505c264d3c742b65dfdac80231aaa48097ade8'/>
<id>4b505c264d3c742b65dfdac80231aaa48097ade8</id>
<content type='text'>
Previously, we included &lt;xlocale.h&gt; only if necessary to get the definition
of type locale_t.  According to notes in PGAC_TYPE_LOCALE_T, this is
important because on some versions of glibc that file supplies an
incompatible declaration of locale_t.  (This info may be obsolete, because
on my RHEL6 box that seems to be the *only* definition of locale_t; but
there may still be glibc's in the wild for which it's a live concern.)

It turns out though that on FreeBSD and maybe other BSDen, you can get
locale_t from stdlib.h or locale.h but mbstowcs_l() and friends only from
&lt;xlocale.h&gt;.  This was leaving us compiling calls to mbstowcs_l() and
friends with no visible prototype, which causes a warning and could
possibly cause actual trouble, since it's not declared to return int.

Hence, adjust the configure checks so that we'll include &lt;xlocale.h&gt;
either if it's necessary to get type locale_t or if it's necessary to
get a declaration of mbstowcs_l().

Report and patch by Aleksander Alekseev, somewhat whacked around by me.
Back-patch to all supported branches, since we have been using
mbstowcs_l() since 9.1.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, we included &lt;xlocale.h&gt; only if necessary to get the definition
of type locale_t.  According to notes in PGAC_TYPE_LOCALE_T, this is
important because on some versions of glibc that file supplies an
incompatible declaration of locale_t.  (This info may be obsolete, because
on my RHEL6 box that seems to be the *only* definition of locale_t; but
there may still be glibc's in the wild for which it's a live concern.)

It turns out though that on FreeBSD and maybe other BSDen, you can get
locale_t from stdlib.h or locale.h but mbstowcs_l() and friends only from
&lt;xlocale.h&gt;.  This was leaving us compiling calls to mbstowcs_l() and
friends with no visible prototype, which causes a warning and could
possibly cause actual trouble, since it's not declared to return int.

Hence, adjust the configure checks so that we'll include &lt;xlocale.h&gt;
either if it's necessary to get type locale_t or if it's necessary to
get a declaration of mbstowcs_l().

Report and patch by Aleksander Alekseev, somewhat whacked around by me.
Back-patch to all supported branches, since we have been using
mbstowcs_l() since 9.1.
</pre>
</div>
</content>
</entry>
</feed>
