documentation tarball builds.

>
> 1. Now outputs '\\' instead of '\134' when using encode(bytea, 'escape')
> Note that I ended up leaving \0 as \000 so that there are no ambiguities
> when decoding something like, for example, \0123.
>
> 2. Fixed bug in byteain which allowed input values which were not valid
> octals (e.g. \789), to be parsed as if they were octals.
>
> Joe
>

Here's rev 2 of the bytea string support patch. Changes:

1. Added missing declaration for MatchBytea function
2. Added PQescapeBytea to fe-exec.c
3. Applies cleanly on cvs tip from this afternoon

I'm hoping that someone can review/approve/apply this before beta starts, so
I guess I'd vote (not that it counts for much) to delay beta a few days :-)

Joe Conway

unicode-conversion is always on if --enable-multibyte is specified

	   Tatsuo Ishii

    Tatsuo Ishii

    Tatsuo Ishii

    Tatsuo Ishii

CREATE RULE bad_rule_combination_1 AS
    ON SELECT TO emp
    DO INSTEAD
        SELECT * FROM toyemp;

CREATE RULE bad_rule_combination_2 AS
    ON SELECT TO toyemp
    DO INSTEAD
        SELECT * FROM emp;

	Tatsuo Ishii

    Tatsuo Ishii

Hiroshi Inoue

   older versions of servers.
2) Implement SQLProcedures.

Hiroshi Inoue

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)