[COMMITTERS] pginstaller - web: Make download link in the FAQ always point to the

2007-07-18 Thread User Mha
Log Message:
---
Make download link in the FAQ always point to the latest version

Modified Files:
--
web/faq:
FAQ_windows.html (r1.12 -> r1.13)

(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pginstaller/web/faq/FAQ_windows.html.diff?r1=1.12&r2=1.13)
FAQ_windows_ja.html (r1.6 -> r1.7)

(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pginstaller/web/faq/FAQ_windows_ja.html.diff?r1=1.6&r2=1.7)

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


[COMMITTERS] pginstaller - web: Correct python version, per Magnus

2007-07-18 Thread User Dpage
Log Message:
---
Correct python version, per Magnus

Modified Files:
--
web:
index.html (r1.8 -> r1.9)

(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pginstaller/web/index.html.diff?r1=1.8&r2=1.9)

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


[COMMITTERS] pginstaller - web: Update Turkish translation and fix links.

2007-07-18 Thread User Mha
Log Message:
---
Update Turkish translation and fix links.

Devrim.

Modified Files:
--
web/faq:
FAQ_windows_tr.html (r1.2 -> r1.3)

(http://cvs.pgfoundry.org/cgi-bin/cvsweb.cgi/pginstaller/web/faq/FAQ_windows_tr.html.diff?r1=1.2&r2=1.3)

---(end of broadcast)---
TIP 6: explain analyze is your friend


[COMMITTERS] pgsql: GSSAPI documentation

2007-07-18 Thread Magnus Hagander
Log Message:
---
GSSAPI documentation

Modified Files:
--
pgsql/doc/src/sgml:
client-auth.sgml (r1.98 -> r1.99)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/client-auth.sgml.diff?r1=1.98&r2=1.99)
config.sgml (r1.130 -> r1.131)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/config.sgml.diff?r1=1.130&r2=1.131)
installation.sgml (r1.289 -> r1.290)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/installation.sgml.diff?r1=1.289&r2=1.290)
libpq.sgml (r1.237 -> r1.238)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/libpq.sgml.diff?r1=1.237&r2=1.238)
protocol.sgml (r1.67 -> r1.68)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/protocol.sgml.diff?r1=1.67&r2=1.68)

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [COMMITTERS] pgsql: Document that age() adds days, then full months.

2007-07-18 Thread Tom Lane
[EMAIL PROTECTED] (Bruce Momjian) writes:
> Document that age() adds days, then full months.

AFAICT, this documentation "improvement" is outright wrong.

regards, tom lane

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


[COMMITTERS] pgsql: Cast NULL to a pointer type in the execl() call, to avoid a

2007-07-18 Thread Alvaro Herrera
Log Message:
---
Cast NULL to a pointer type in the execl() call, to avoid a compiler warning on
some platforms and possibly a bug.  Per report from Stefan and subsequent
discussion.

Modified Files:
--
pgsql/src/test/regress:
pg_regress.c (r1.35 -> r1.36)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/pg_regress.c.diff?r1=1.35&r2=1.36)

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


[COMMITTERS] pgsql: Fix an old thinko in SS_make_initplan_from_plan, which is used

2007-07-18 Thread Tom Lane
Log Message:
---
Fix an old thinko in SS_make_initplan_from_plan, which is used when optimizing
a MIN or MAX aggregate call into an indexscan: the initplan is being made at
the current query nesting level and so we shouldn't increment query_level.
Though usually harmless, this mistake could lead to bogus "plan should not
reference subplan's variable" failures on complex queries.  Per bug report
from David Sanchez i Gregori.

Modified Files:
--
pgsql/src/backend/optimizer/plan:
subselect.c (r1.122 -> r1.123)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/subselect.c.diff?r1=1.122&r2=1.123)
pgsql/src/test/regress/expected:
subselect.out (r1.15 -> r1.16)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/subselect.out.diff?r1=1.15&r2=1.16)
pgsql/src/test/regress/sql:
subselect.sql (r1.10 -> r1.11)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/subselect.sql.diff?r1=1.10&r2=1.11)

---(end of broadcast)---
TIP 6: explain analyze is your friend


[COMMITTERS] pgsql: Fix an old thinko in SS_make_initplan_from_plan, which is used

2007-07-18 Thread Tom Lane
Log Message:
---
Fix an old thinko in SS_make_initplan_from_plan, which is used when optimizing
a MIN or MAX aggregate call into an indexscan: the initplan is being made at
the current query nesting level and so we shouldn't increment query_level.
Though usually harmless, this mistake could lead to bogus "plan should not
reference subplan's variable" failures on complex queries.  Per bug report
from David Sanchez i Gregori.

Tags:

REL8_2_STABLE

Modified Files:
--
pgsql/src/backend/optimizer/plan:
subselect.c (r1.112.2.1 -> r1.112.2.2)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/subselect.c.diff?r1=1.112.2.1&r2=1.112.2.2)
pgsql/src/test/regress/expected:
subselect.out (r1.14 -> r1.14.2.1)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/subselect.out.diff?r1=1.14&r2=1.14.2.1)
pgsql/src/test/regress/sql:
subselect.sql (r1.9 -> r1.9.2.1)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/subselect.sql.diff?r1=1.9&r2=1.9.2.1)

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


[COMMITTERS] pgsql: Fix an old thinko in SS_make_initplan_from_plan, which is used

2007-07-18 Thread Tom Lane
Log Message:
---
Fix an old thinko in SS_make_initplan_from_plan, which is used when optimizing
a MIN or MAX aggregate call into an indexscan: the initplan is being made at
the current query nesting level and so we shouldn't increment query_level.
Though usually harmless, this mistake could lead to bogus "plan should not
reference subplan's variable" failures on complex queries.  Per bug report
from David Sanchez i Gregori.

Tags:

REL8_1_STABLE

Modified Files:
--
pgsql/src/backend/optimizer/plan:
subselect.c (r1.100.2.3 -> r1.100.2.4)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/optimizer/plan/subselect.c.diff?r1=1.100.2.3&r2=1.100.2.4)
pgsql/src/test/regress/expected:
subselect.out (r1.13.2.1 -> r1.13.2.2)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/expected/subselect.out.diff?r1=1.13.2.1&r2=1.13.2.2)
pgsql/src/test/regress/sql:
subselect.sql (r1.8.2.1 -> r1.8.2.2)

(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/test/regress/sql/subselect.sql.diff?r1=1.8.2.1&r2=1.8.2.2)

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [COMMITTERS] pgsql: Document that age() adds days, then full months.

2007-07-18 Thread Bruce Momjian
Tom Lane wrote:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
> > Document that age() adds days, then full months.
> 
> AFAICT, this documentation "improvement" is outright wrong.

I am now thinking no documentation paragraph is even needed. We have to
use the number of months in the earlier date or simple computations
would not work like:

test=> select age('2004-05-29', '2004-06-28');
   age
--
 -30 days
(1 row)

The end of the earlier month is part of the interval between the two
timestamps, while the end of the later month is not.  Of course with a
multi-months span there are more chances for variance, but we certainly
should give the right answer for an interval < 1 month.  I can just add
a C comment.

-- 
  Bruce Momjian  <[EMAIL PROTECTED]>  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate