<listitem><para> Dollar sign (<literal>$</>) is no longer allowed
in operator names</para></listitem>
<listitem><para> Dollar sign (<literal>$</>) can be a non-first
character in identifiers</para></listitem>
> only think to look at sort_mem if they already had a clue. It should
> be mentioned under bulk data load (in performance tips chapter)
Attached is a doc patch that does this. The way I've worded it may not
be the best, though.
Neil Conway
I suggest adding LOCALTIMESTAMP and LOCALTIME to the first paragraph.
Maybe it should be phrased as:
The following SQL-compatible functions can be used to obtain
current datetime-related values: CURRENT_DATE, CURRENT_TIME,
CURRENT_TIMESTAMP, LOCALTIME and LOCALTIMESTAMP.
(See Section 9.8.4.)
Troels Arvin
before it is de-backslashed, not after. This allows the null string \N
to be reliably distinguished from the data value \N (which must be
represented as \\N). Per bug report from Manfred Koizar ... but it's
amazing this hasn't been reported before ...
Also, be consistent about encoding conversion for null string: the form
specified in the command is in the server encoding, but what is sent
to/from client must be in client encoding. This never worked quite
right before either.
will downcase the supplied field name unless it is double-quoted. Also,
upgrade the routine's handling of double quotes to match the backend,
in particular support doubled double quotes within quoted identifiers.
Per pgsql-interfaces discussion a couple weeks ago.
of function bodies is done at CREATE FUNCTION time. This is normally
true but can be set false to avoid problems with forward references,
wrong schema search path, etc. This is just the backend patch, still
need to adjust pg_dump to make use of it.
invalid (has the wrong magic number) until the build is entirely
complete. This turns out to cost no additional writes in the normal
case, since we were rewriting the metapage at the end of the process
anyway. In normal scenarios there's no real gain in security, because
a failed index build would roll back the transaction leaving an unused
index file, but for rebuilding shared system indexes this seems to add
some useful protection.
> > a) Write documentation how the win32 console needs to be set up so that
> > psql can handle 8-bit characters.
> > Where should it be added? The Section "Installation on Windows" in the
> > Administrator's Guide seems natural to me.
> >
> > b) Add code to psql that prints a warning on startup of psql when the
> > console codepage differs from the windows codepage, something like
> >
> > Warning: Console codepage (850) differs from windows codepage (1252)
> > 8-bit characters will not work correctly. See PostgreSQL
> > documentation "Installation on Windows" for details.
>
Attached are two patches:
- installdoc.patch contains an additional paragraph on the win32 console
codepage for the chapter "Installation on Windows"
Due to a lack of SGML-tools, I have only edited the text and not tested
the SGML code - please check it before merging into the CVS branch.
- psqlcodepage.patch adds the warning about a problematic codepage to psql.
Christoph Dalitz
now able to cope with assigning new relfilenode values to nailed-in-cache
indexes, so they can be reindexed using the fully crash-safe method. This
leaves only shared system indexes as special cases. Remove the 'index
deactivation' code, since it provides no useful protection in the shared-
index case. Require reindexing of shared indexes to be done in standalone
mode, but remove other restrictions on REINDEX. -P (IgnoreSystemIndexes)
now prevents using indexes for lookups, but does not disable index updates.
It is therefore safe to allow from PGOPTIONS. Upshot: reindexing system catalogs
can be done without a standalone backend for all cases except
shared catalogs.
to control object ownership. The use-set-session-authorization and
no-reconnect switches are obsolete (still accepted on the command line,
but they don't do anything). This is a precursor to fixing handling
of CREATE SCHEMA, which will be a separate commit.
Per recent discussion, this does not work because other backends can't
reliably see tuples in a temp table and so cannot run the RI checks
correctly. Seems better to disallow this case than go back to accessing
temp tables through shared buffers. Also, disallow FK references to
ON COMMIT DELETE ROWS tables. We already caught this problem for normal
TRUNCATE, but the path used by ON COMMIT didn't check.
comments/examples in pg_hba.conf. This patch remedies that, adds a brief
explanation of the connection types, and adds a missing period in the
docs.
Jon Jensen
