[DOCS] Request temporary freeze of libpgtcl chapter in manual
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 reference manual, but has been expanded, and portions were rewritten. I would like to request that no changes be made to the libpgtcl chapter in the PostgreSQL reference manual, at least for the near term, beyond file revision 1.40 in CVS. Otherwise, I can't promise any changes you make will end up in my version of the manual, in the event that the unbundling effort is successful. Is this OK? ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [DOCS] Pgtcl manual online / was: Request temporary freeze of libpgtcl...
[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 Gforge would give us? > > Anyone know what the guys working on the perl interface have done? My mistake. I see that the Perl interface documentation was never part of the PostgreSQL Programmer's Manual. The Perl interface documentation lives inside the Pg.pm file and ends up installed and readable with perldoc. Bad example. I think there was a request on Gborg about project documentation, and the answer was to use the "genpage" feature. That's OK for a few pages with little cross-referencing, but I don't think it is practical for DocBook-generated manuals. Perhaps it isn't that important to have an unpacked version of the manual readable on the web. But for this first release, I just wanted to make it easier for people to look at, especially those who might be asking: are we unbundled yet? ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [DOCS] [GENERAL] Gripe: bytea_output default => data corruption
[email protected] 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 be best to remove escaping details here. But the description of PQescapeBytea() might need to be rewritten, too. Without describing exactly what PQescapeByteaConn() does, it is hard to understand what PQescapeBytea() does not do, and why it therefore "might give the wrong results". I think the actual function behavior should be documented somewhere. Even though it might change again. -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [GENERAL] Gripe: bytea_output default => data corruption
[email protected] 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, implying that PQescapeByteaConn does adjust its behavior based on byte_output. Wrong! Neither one knows or cares about the bytea_output parameter, which is solely for the backend to tell it how to present bytea data to the front-end. Not for the front-ends at all. (See why we need this behavior documented?) Non-use of 'standard_conforming_strings' is also wrong, in the current (pre-patched) docs. PQescapeBytea does adjust its behavior for standard_conforming_strings, but only for the single-connection case. See similar text for PQescapeString. Regarding the first paragraph changed, it seems off to me. "PQescapeByteConn escapes such bytes using either hex encoding..." tells me that when hex encoding is used, PQescapeByte encodes only bytes that need escaping. Not true - hex encoding encodes (not escapes) every byte. -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [GENERAL] Gripe: bytea_output default => data corruption
[email protected] 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 like the change. This: "is that PQescapeBytea does not take a PGconn or error parameters" is wrong. PQescapeByteaConn does not take an 'error' parameter either. Also "no way to report error conditions" is wrong. It returns NULL on an error; it just cannot return a specific error message. (Which is OK because there is only one, unlikely error: out of memory.) Reading the before/after text here, I don't see anything that needs changing except for dropping the reference to single-threaded (same as for PQescapeString). I suggest going back to the original text and just changing: From: "can be used safely in single-threaded client programs that work with only one" to: "can only be used safely in client programs that use a single" (Sorry for the trouble. I should have fully commented on the first one, but I find it hard to see the changes with these "git" diffs of SGML.) -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] [GENERAL] Gripe: bytea_output default => data corruption
[email protected] 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 ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
