This shouldn't affect simple indexscans much, while for bitmap scans that
are touching a lot of index rows, this seems to bring the estimates more
in line with reality.  Per recent discussion.

assumed that a sequential page fetch has cost 1.0.  This patch doesn't
in itself change the system's behavior at all, but it opens the door to
people adopting other units of measurement for EXPLAIN costs.  Also, if
we ever decide it's worth inventing per-tablespace access cost settings,
this change provides a workable intellectual framework for that.

the query.

< * %Remove behavior of postmaster -o
> * %Make postmater and postgres options distinct so the postmaster -o
>   option is no longer needed

< 	o Allow COPY to output from views
> 	o Allow COPY to output from SELECT
570c570
< 	  Another idea would be to allow actual SELECT statements in a COPY.
> 	  COPY should also be able to output views.

Robert Treat

Robert Treat

for LC_MESSAGES; instead, just press forward, leaving the effective setting
at 'C'.  There is not any very good reason to complain when we are going
to replace the value soon with whatever postgresql.conf says.  This change
should solve the occasionally-reported problem of initdb failing with
'failed to initialize lc_messages'; the current theory is that that is
a reflection of either wrong LANG/LC_MESSAGES or completely broken locale
support.

HAVE_INT64_TIMESTAMP was mentioning PG_CONTROL_VERSION instead.
Victor Snezhko

>  * Allow WAL information to recover corrupted pg_controldata
>
>   See partially completed patch and additional work required at
>   http://archives.postgresql.org/pgsql-patches/2006-06/msg00025.php.
>

Per Larry Rosenman.

> * Allow WAL information to recover corrupted pg_controldata

	http://archives.postgresql.org/pgsql-hackers/2006-05/msg00002.php

allow only recognized words in thezaurus configuration file.

see if using an intermediate variable avoids the gcc bug.

E'...' syntax for strings in order to track the backend.

and there's only one place that's a kluge, ie, appendStringLiteralConn.
Note that pg_dump itself doesn't use appendStringLiteralConn, so its
behavior is not affected; only the other utility programs care.

NOT the thing to use here.

the server.  Per discussion, there seems no point in a waiting period
before making this required.

It required some changes in lexize algorithm, but interface with
dictionaries stays compatible with old dictionaries.

Funded by Georgia Public Library Service and LibLime, Inc.

        o  turns off escape_string_warning in pg_dumpall.c
        o  optionally use E'' for \password (undocumented option?)
        o  honor standard_conforming-strings for \copy (but not
           support literal E'' strings)
        o  optionally use E'' for \d commands
        o  turn off escape_string_warning for createdb, createuser,
           droplang

in every shared library.

as this seems only likely to create headaches for module developers.  Put
the macro in the pre-existing fmgr.h file instead.  Avoid being too cute
about how many fields we can cram into a word, and avoid trying to fetch
from a library we've already unlinked.
Along the way, it occurred to me that the magic block really ought to be
'const' so it can be stored in the program text area.  Do the same for
the existing data blocks for PG_FUNCTION_INFO_V1 functions.

across multiple loops, get rid of the shaky assumption that exactly one
tuple is returned per node iteration.

This is just the minimal necessary change; we might want to adopt
later PPPort output instead.

It now only checks four things:

Major version number (7.4 or 8.1 for example)
NAMEDATALEN
FUNC_MAX_ARGS
INDEX_MAX_KEYS

The three constants were chosen because:

1. We document them in the config page in the docs
2. We mark them as changable in pg_config_manual.h
3. Changing any of these will break some of the more popular modules:

FUNC_MAX_ARGS changes fmgr interface, every module uses this NAMEDATALEN
changes syscache interface, every PL as well as tsearch uses this
INDEX_MAX_KEYS breaks tsearch and anything using GiST.

Martijn van Oosterhout

Martijn van Oosterhout

demonstrating that its intent wasn't obvious.

Martijn van Oosterhout