Log Message:
---
New: [#1011021] Support DbMetaDataCollectionNames.ReservedWords. Thanks Patrick
Earl for patch.
Modified Files:
--
Npgsql2/src/Npgsql:
NpgsqlConnection.cs (r1.31 -> r1.32)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/npgsql/Npgsql2/src/Np
Use an explicit format string to keep the compiler happy.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/c43d0791ac5fb765a088d41564cd44747aef42d8
Modified Files
--
src/backend/port/win32/security.c |6 +++---
1 files changed, 3 insertions(+), 3 deleti
Force use of "%I64d" format for 64 bit ints on MinGW.
Both this and "%lld" work, but the compiler's format checking doesn't
like "%lld", so we get all sorts of spurious warnings.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/52d01c2f52c462d29ae0fdfa44c3cae129148a6d
Remove hard coded formats for INT64 and use configured settings instead.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/9b1508af8971c1627cda5bb65f5e9eddb9a1a55e
Modified Files
--
src/backend/postmaster/postmaster.c |2 +-
src/interfaces/ecpg/ecpglib
Andrew Dunstan writes:
> Remove hard coded formats for INT64 and use configured settings instead.
I don't find this patch to be a good idea. The code was unconditionally
correct before, and now it isn't:
- sprintf(mallocedval + strlen(mallocedval), "%lld,",
((long long in
Revert "Remove hard coded formats for INT64 and use configured settings
instead."
This reverts commit 9b1508af8971c1627cda5bb65f5e9eddb9a1a55e.
As requested by Tom.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/348c10efe08f01872daeeb62f32c8e362fcbba69
Modified F
Fix array- and path-creating functions to ensure padding bytes are zeroes.
Per recent discussion, it's important for all computed datums (not only the
results of input functions) to not contain any ill-defined (uninitialized)
bits. Failing to ensure that can result in equal() reporting that
seman
Fix array- and path-creating functions to ensure padding bytes are zeroes.
Per recent discussion, it's important for all computed datums (not only the
results of input functions) to not contain any ill-defined (uninitialized)
bits. Failing to ensure that can result in equal() reporting that
seman
Fix array- and path-creating functions to ensure padding bytes are zeroes.
Per recent discussion, it's important for all computed datums (not only the
results of input functions) to not contain any ill-defined (uninitialized)
bits. Failing to ensure that can result in equal() reporting that
seman
Fix array- and path-creating functions to ensure padding bytes are zeroes.
Per recent discussion, it's important for all computed datums (not only the
results of input functions) to not contain any ill-defined (uninitialized)
bits. Failing to ensure that can result in equal() reporting that
seman
Fix array- and path-creating functions to ensure padding bytes are zeroes.
Per recent discussion, it's important for all computed datums (not only the
results of input functions) to not contain any ill-defined (uninitialized)
bits. Failing to ensure that can result in equal() reporting that
seman
Add comments about the need to avoid uninitialized bits in datatype values.
There was already one recommendation in the documentation about writing
C functions to ensure padding bytes are zeroes, but make it stronger.
Also fix an example that was still using direct assignment to a varlena
length
Add comments about the need to avoid uninitialized bits in datatype values.
There was already one recommendation in the documentation about writing
C functions to ensure padding bytes are zeroes, but make it stronger.
Also fix an example that was still using direct assignment to a varlena
length
timeline is not needed in BaseBackup()
This code was accidentally part of the patch, it's only
needed for the code that's for 9.2. Not needing the timeline
also removes the need to call IDENTIFY_SYSTEM.
Noted by Peter E.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdi
Revert "Force use of "%I64d" format for 64 bit ints on MinGW."
This reverts commit 52d01c2f52c462d29ae0fdfa44c3cae129148a6d.
the UINT64_FORMAT bit broke the b uildfarm, so I'm reverting the whole thing
pending further investigation.
Branch
--
master
Details
---
http://git.postgresql.or
Excerpts from Tom Lane's message of lun abr 25 17:22:41 -0300 2011:
> Fix pg_size_pretty() to avoid overflow for inputs close to INT64_MAX.
>
> The expression that tried to round the value to the nearest TB could
> overflow, leading to bogus output as reported in bug #5993 from Nicola
> Cossu. Th
Fix binary upgrade of altered typed tables
Instead of dumping them as CREATE TABLE ... OF, dump them as normal
tables with the usual special processing for dropped columns, and then
attach them to the type afterward, using ALTER TABLE ... OF. This is
analogous to the existing handling of inherite
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of lun abr 25 17:22:41 -0300 2011:
>> Fix pg_size_pretty() to avoid overflow for inputs close to INT64_MAX.
> Apparently this change is causing Moa's SunStudio compiler to fail an
> assertion.
[ scratches head... ] Hard to see why, there
Excerpts from Tom Lane's message of mié abr 27 17:10:37 -0300 2011:
> Alvaro Herrera writes:
> > Excerpts from Tom Lane's message of lun abr 25 17:22:41 -0300 2011:
> >> Fix pg_size_pretty() to avoid overflow for inputs close to INT64_MAX.
>
> > Apparently this change is causing Moa's SunStudio c
Make a quick copy-editing pass over the 9.1 release notes.
Also remove the material about this being an alpha release.
The notes still need a lot of work, but they're more or less presentable
as a beta version now.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/bb1
Tag 9.1beta1.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/993c5e59047dd568d4831f7ec5c6199acd21f17f
Modified Files
--
configure | 18 +-
configure.in |2 +-
doc/bug.template |2 +
Log Message:
---
Prep release 09.00.0300.
Modified Files:
--
psqlodbc:
configure.ac (r1.92 -> r1.93)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/psqlodbc/psqlodbc/configure.ac?r1=1.92&r2=1.93)
version.h (r1.188 -> r1.189)
(http://cvs.pgfou
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of mié abr 27 17:10:37 -0300 2011:
>> Alvaro Herrera writes:
>>> Apparently this change is causing Moa's SunStudio compiler to fail an
>>> assertion.
>> [ scratches head... ] Hard to see why, there's nothing at all
>> interesting in tha
23 matches
Mail list logo
