Hiroshi Inoue

> null bytes to be literally '\0', the following can happen:
> 1. User inputs string value as "<null byte>##" where ## are digits in the
> range of 0 to 7.
> 2. PQescapeString converts this to "\0##"
> 3. Escaped string is used in a context that causes "\0##" to be evaluated as
> an octal escape sequence.

I agree that this is a problem, though it is not possible to do
anything harmful with it.  In addition, it only occurs if there are
any NUL characters in its input, which is very unlikely if you are
using C strings.

The patch below addresses the issue by removing escaping of \0
characters entirely.

> If the goal is to "safely" encode null bytes, and preserve the rest of the
> string as it was entered, I think the null bytes should be escaped as \\000
> (note that if you simply use \000 the same string truncation problem
> occurs).

We can't do that, this would require 4n + 1 bytes of storage for the
result, breaking the interface.

Florian Weimer

2) (Maybe) fix a bug reported by Mika Muntila.

Correction content:
  * I revised a mistake of type (copy and paste).
  * I revised multiplicity of description.

Ryouichi Matsuda

doc).

Hiroyuki Yatabe

max_locks_per_xact.

bugfix is in the attached patch. Please apply it. Thanks.

 Output must be:

test=# SELECT to_char(485, 'RN');
     to_char
-----------------
         CDLXXXV
(1 row)

test=# SELECT to_char(485, 'FMRN');
 to_char
---------
 CDLXXXV
(1 row)

test=# SELECT to_char(1000, 'RN');
     to_char
-----------------
               M
(1 row)


test=# SELECT to_char(7.2, '"Welcome to"9.9 "release! :-)"');
           to_char
-----------------------------
 Welcome to 7.2 release! :-)
(1 row)

Karel Zak

undocumented items in TD.

Should doc patches alse be sent to pgsql-patches, or do I
have to subscribe to pgsql-docs?

The archive link for pgsql-patches is broken, and I don't
see any patches in spot checking the archive for pgsql-docs.

-Brad McLean.

a trigger the way that pltcl does.

Here's a little patch that adds it in.

-Brad McLean

reported by Bob Deblier (bob@virtualunlimited.com)

suggested by Bob Deblier (bob@virtualunlimited.com)

partially from Kenji Sugita

Psqlodbc is 7.01.0007 now.

Hiroshi Inoue

* Reject character sequences those are not valid in their charset

* Reject character sequences those are not valid in their charset

fall back to `cd $srcdir && /bin/pwd` = `/bin/pwd`.  One of these ought to
work, and if not, prep_buildtree is harmless.

from Ian Lance Taylor

(partially) from Ian Lance Taylor

driver's test suite. With previous patches applied, this reduces
the number of failures of the test suite from 6 to 4. The patch
fixes the test case itself, rather than the driver.

Details:

1) The driver correctly provided DatabaseMetaData about the sort
order of NULLs. This was confirmed by Peter Eisentraut on
pgsql-hackers. I fixed the test to accept/require the current
behaviour, and made it dependent on the backend version. See
nullsAreSortedAtStart(), nullsAreSortedAtEnd(),
nullsAreSortedHigh() and nullsAreSortedLow().

2) DatabaseMetaData.supportsOrderByUnrelated() correctly
returned true (an ORDER BY clause can contain columns that are
not in the SELECT clause), but the test case required false.
Fixed that.

3) Replaced deprecated assert() of junit.framework.TestCase by
assertEquals(), assertTrue() and assertNotNull(). This is
because assert will be a new keyword in Java 1.4.

4) Replaced assert(message,false) by the more elegant
fail(message).

Regards,
Ren? Pijlman <rene@lab.applinet.nl>