On Fri, 2007-11-09 at 11:28 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Fri, 2007-11-09 at 04:05 -0500, Tom Lane wrote:
> >> That was my first reaction too, but the point about unique-index behavior
> >> refutes it. Constraining a table to have at most one row is useful
Log Message:
---
Another 8.3 data type issue... using '0' allows comparison
against int or text, since the type isnt determined until
compare time.
Modified Files:
--
mysqlcompat:
string.sql (r1.12 -> r1.13)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/my
Log Message:
---
we also need a version for int vars for oct() to work
Modified Files:
--
mysqlcompat:
string.sql (r1.13 -> r1.14)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/mysqlcompat/mysqlcompat/string.sql.diff?r1=1.13&r2=1.14)
---
Log Message:
---
Have crosstab variants treat NULL rowid as a category in its own right,
per suggestion from Tom Lane. This fixes crash-bug reported by Stefan
Schwarzer.
Tags:
REL7_3_STABLE
Modified Files:
--
pgsql/contrib/tablefunc:
tablefunc.c (r1.10.2.3 ->
Log Message:
---
Have crosstab variants treat NULL rowid as a category in its own right,
per suggestion from Tom Lane. This fixes crash-bug reported by Stefan
Schwarzer.
Tags:
REL7_4_STABLE
Modified Files:
--
pgsql/contrib/tablefunc:
tablefunc.c (r1.25.2.2 ->
Log Message:
---
Have crosstab variants treat NULL rowid as a category in its own right,
per suggestion from Tom Lane. This fixes crash-bug reported by Stefan
Schwarzer.
Tags:
REL8_0_STABLE
Modified Files:
--
pgsql/contrib/tablefunc:
tablefunc.c (r1.34 -> r1.3
Log Message:
---
Have crosstab variants treat NULL rowid as a category in its own right,
per suggestion from Tom Lane. This fixes crash-bug reported by Stefan
Schwarzer.
Tags:
REL8_1_STABLE
Modified Files:
--
pgsql/contrib/tablefunc:
tablefunc.c (r1.38.2.1 ->
Log Message:
---
Have crosstab variants treat NULL rowid as a category in its own right,
per suggestion from Tom Lane. This fixes crash-bug reported by Stefan
Schwarzer.
Tags:
REL8_2_STABLE
Modified Files:
--
pgsql/contrib/tablefunc:
tablefunc.c (r1.45 -> r1.4
Log Message:
---
Have crosstab variants treat NULL rowid as a category in its own right,
per suggestion from Tom Lane. This fixes crash-bug reported by Stefan
Schwarzer.
Modified Files:
--
pgsql/contrib/tablefunc:
tablefunc.c (r1.47 -> r1.48)
(http://develo
Log Message:
---
Properly order pg_ctl -c option alphabetically in docs.
Modified Files:
--
pgsql/doc/src/sgml/ref:
pg_ctl-ref.sgml (r1.41 -> r1.42)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/ref/pg_ctl-ref.sgml?r1=1.41&r2=1.42)
---
Log Message:
---
the 1 and 0 need to be quoted in 8.3, lest they be interpreted as integers by
replace
Modified Files:
--
mysqlcompat:
string.sql (r1.11 -> r1.12)
(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/mysqlcompat/mysqlcompat/string.sql.diff?r1=1.11&
Log Message:
---
Recognize RETURN QUERY via a textual test, so that QUERY doesn't need to be
a plpgsql keyword. This avoids springing a new reserved word on plpgsql
programmers.
For consistency, handle RETURN NEXT the same way.
Modified Files:
--
pgsql/src/pl/plpgsql/src:
Log Message:
---
Add an expected-results file to get regression to pass cleanly in sv_SE
locale, which sorts a bit differently. Per recent gripe from Magnus.
Added Files:
---
pgsql/src/test/regress/expected:
select_1.out (r1.1)
(http://developer.postgresql.org
Log Message:
---
Clean up ts_locale.h/.c. Fix broken and not-consistent-across-platforms
behavior of wchar2char/char2wchar; this should resolve bug #3730. Avoid
excess computations of pg_mblen in t_isalpha and friends. Const-ify
APIs where possible.
Modified Files:
--
pg
Log Message:
---
Point to our own UUID page instead of to Wikipedia.
Modified Files:
--
pgsql/doc/src/sgml:
acronyms.sgml (r1.3 -> r1.4)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/acronyms.sgml?r1=1.3&r2=1.4)
---
Log Message:
---
Second pass at improving LIKE/regex estimation in non-C locales. It turns
out that it's actually quite likely that a string that is an extension of
the given prefix will sort as larger than the "greater" string our previous
code created. To provide some defense against th
Log Message:
---
Second pass at improving LIKE/regex estimation in non-C locales. It turns
out that it's actually quite likely that a string that is an extension of
the given prefix will sort as larger than the "greater" string our previous
code created. To provide some defense against th
Log Message:
---
Second pass at improving LIKE/regex estimation in non-C locales. It turns
out that it's actually quite likely that a string that is an extension of
the given prefix will sort as larger than the "greater" string our previous
code created. To provide some defense against th
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>
>> Sure is, and I've done it just a few days ago.
>
>> This SQL does it using standard syntax:
>
>> create table foo (handle integer primary key check (handle = 1));
>
> That does not constrain the table to have o
Log Message:
---
Add parameter krb_realm used by GSSAPI, SSPI and Kerberos
to validate the realm of the connecting user. By default
it's empty meaning no verification, which is the way
Kerberos authentication has traditionally worked in
PostgreSQL.
Modified Files:
--
pgsql/
Log Message:
---
Move pl/proxy into Multi-server parallel query execution documentation
section.
Modified Files:
--
pgsql/doc/src/sgml:
high-availability.sgml (r1.21 -> r1.22)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/high-availability.
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Fri, 2007-11-09 at 04:05 -0500, Tom Lane wrote:
>> That was my first reaction too, but the point about unique-index behavior
>> refutes it. Constraining a table to have at most one row is useful.
> Sure is, and I've done it just a few days ago.
> This
Log Message:
---
Allow XML processing instructions starting with "xml" while prohibiting
those being exactly "xml". Bug #3735 from Ben Leslie
Modified Files:
--
pgsql/src/backend/utils/adt:
xml.c (r1.53 -> r1.54)
(http://developer.postgresql.org/cvsweb.cgi
On Fri, 2007-11-09 at 04:05 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I had understood the discussion to conclude that indexes that do not
> > depend on any column of the table to not be allowed at all.
>
> That was my first reaction too, but the point about unique-index
Simon Riggs <[EMAIL PROTECTED]> writes:
> I had understood the discussion to conclude that indexes that do not
> depend on any column of the table to not be allowed at all.
That was my first reaction too, but the point about unique-index behavior
refutes it. Constraining a table to have at most o
On Thu, 2007-11-08 at 23:22 +, Tom Lane wrote:
> Log Message:
> ---
> If an index depends on no columns of its table, give it a dependency on the
> whole table instead, to ensure that it goes away when the table is dropped.
> Per bug #3723 from Sam Mason.
>
> Backpatch as far as 7.4; A
26 matches
Mail list logo
