br...@momjian.us wrote:
>...
> OK, updated version attached. I keep most of the new patch for the
> PQescapeBytea docs rather than use most of the original so it would
> match text for other escape functions.
Looks good to me.
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To m
br...@momjian.us wrote:
> Here is an updated patch, again to be backpatched to 9.0.
Getting better.
In change block 1, after PQescapeString synopsis:
Change: "does not take a Pgconn or error parameters"
to: "does not take Pgconn or error parameters"
In change block 4, PQescapeBytea, I don't
br...@momjian.us wrote:
>...
>> Based on this report, I have created the attached documentation patch
>> which clarifies the libpq behavior for escaping bytea. I am planning to
>> backpatch this to 9.0 as well.
This change says PQescapeBytea is unable to adjust its behavior based on
bytea_output,
t...@sss.pgh.pa.us wrote:
> I think we should simply remove the description of *how* the escaping is
> performed, and state only that the function produces a suitably escaped
> literal string. Anything else is not future-proof, and could someday
> break the way this wording did.
Perhaps it would
[EMAIL PROTECTED] wrote:
>...
>
> I'd prefer to have the documentation live closer to the project than to have
> it up on techdocs, though techdocs is probably better than someone personal
> home page.
>
> Chris, is there some way to accomplish this with gborg?
>
> Josh, is this something that
I have a new project to extend and finish up pgtcl, the Tcl interface to
PostgreSQL. This continues the effort to unbundle interfaces from the
PostgreSQL core. Along with the software, I will be releasing a
stand-alone reference manual, which started life as libpgtcl.sgml from the
PostgreSQL core
