subpath(ltree,0,0) returns ''.

> Well, no. What it says is that certain values must be escaped (but
> doesn't say which ones). Then it says there are alternate escape
> sequences for some values, which it lists.
>
> It doesn't say "The following table contains the characters which must
> be escaped:", which would be much clearer (and actually useful).

Attached documentation patch updates the wording for bytea input
escaping, per complaint by Stephen Norris above.

Joe Conway

(BBBB before bbbb) and others the other way around.  Provide comparison
files that cater to both approaches.

date2j().  This ensures we give reasonable errors instead of bizarre
behavior for input dates far in the future.

does not dump core.

database, emit a WARNING and do nothing, rather than raising ERROR.
Per recent discussion in which we concluded this is the best way to deal
with database dumps that are reloaded into a database of a new name.

fixed incorrect initial setting of StartUpID.  The logic in XLogWrite()
expects that Write->curridx is advanced to the next page as soon as
LogwrtResult points to the end of the current page, but StartupXLOG()
failed to make that happen when the old WAL ended exactly on a page
boundary.  Per trouble report from Hannu Krosing.

for the sign of timezone offsets, ie, positive is east from UTC.  These
were previously out of step with other operations that accept or show
timezones, such as I/O of timestamptz values.

query node, since that won't work unless the planner is upgraded.
Someday we should try to support at least some cases of this, but for
now just plug the hole in the dike.  Per discussion with Dmitry Tkach.

with SET TRANSACTION_ISOLATION, either.

DATESTYLE, for instance 'SQL, European' instead of
'SQL with European conventions'.  Per gripe a month or two back from
Barry Lind.

padding logic for struct sockaddr_storage --- original version did not
do what it claimed to when SALEN is defined.

shared_buffers and max_connections values to use before we run the
bootstrap process.  Without this, initdb would fail on platforms where
the hardwired default values are too large.  (We could get around that
by making the hardwired defaults tiny, perhaps, but why slow down
bootstrap by starving it for buffers...)

for each row processed, and don't forget the evaluation cost of any
restriction clauses attached to the node.  Per discussion with Greg Stark.

and 100 respectively, if the platform will allow it.  initdb selects
values that are not too large to allow the postmaster to start, and
places these values in the installed postgresql.conf file.  This allows
us to continue to start up out-of-the-box on platforms with small SHMMAX,
while having somewhat-realistic default settings on platforms with
reasonable SHMMAX.  Per recent pghackers discussion.

ascii.c.

        - Init sqlca in ECPGprepare().
        - Added CLOSE DATABASE for Informix compatibility.

Aizaz Ahmed

to zero.

or increased only by super-users.

This fixes problems caused by making certain variables SUSET for
security reasons.

spec complient with regards to various data/time/timestamp objects

 Modified Files:
 	jdbc/org/postgresql/errors.properties
 	jdbc/org/postgresql/jdbc1/AbstractJdbc1Statement.java

"char *" of course is not the same as "char []". So I had to fix the way ecpg treated the second one.