Clarify libpq docs

Attached is a patch adding a few examples for PREPARE/EXECUTE

Gavin

Gavin Sherry wrote:

The attached patch clarifies (or, rather, makes explicit) to readers
how to handle memory management for char pointers returned by libpq
functions. Although the sections on PQfinish(), PQclear() and
PQfreemem() give an indication that all pointers returned by
functions point to memory allocated in the underlying library, I
thought it would be useful to make this clear.

Please don't put tabs in SGML files. They don't have any real meaning
there. Use spaces to indent. (Normally, we indent code by 4 spaces
and SGML by 1 space.)

Peter Eisentraut <peter_e@gmx.net> writes:

Please don't put tabs in SGML files.

That's a new one on me. Why should we avoid tabs? The existing files
are certainly full of them.

regards, tom lane

Gavin Sherry <swm@linuxworld.com.au> writes:

Attached is a patch adding a few examples for PREPARE/EXECUTE

Patch applied, with a few fixes.

BTW, Bruce and I discussed whether it would be helpful for me to apply
any patches -- and if so, what the proper procedure for doing so
is. What we decided was that I can help out Bruce's patch application
workload (and reduce application latency) by applying a few patches on
occasion. However, I'll only apply relatively small patches that (a)
seem pretty safe and correct (b) I've reviewed myself. Any
comments/objections to this procedure are welcome.

-Neil

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Please don't put tabs in SGML files.

That's a new one on me. Why should we avoid tabs? The existing
files are certainly full of them.

Those are just the files that I haven't edited recently and gave the old
"M-x untabify" treatment...

I ask that tabs be avoided for two reasons: One, we use a one-character
indentation in the source, so it's no use that only every 8th
indentation level is made by a tab, it's just annoying when you're
editing. (The only other indentation scheme for SGML/XML that I see
used is two spaces, so I don't think going to 4 or 8 spaces is in
question.) Two, when rendering, the tabs have questionable meaning.
In HTML they are treated like a single space, who knows what they mean
in a PDF with variable width fonts.

Gavin Sherry <swm@linuxworld.com.au> writes:

The attached patch clarifies (or, rather, makes explicit) to readers how
to handle memory management for char pointers returned by libpq
functions.

Patch applied. I expanded the tabs in that file to 4 spaces, per the
discussion. I also noticed and fixed a few trivial inconsistencies in
the libpq function prototypes.

Thanks for the patches, Gavin.

-Neil