Postgres Pro
Downloads
Home   >   mailing lists

Thread: Clarify libpq docs

Clarify libpq docs

From
Gavin Sherry
Date:
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.

Gavin
Attachment

Examples for PREPARE/EXECUTE docs

From
Gavin Sherry
Date:
Attached is a patch adding a few examples for PREPARE/EXECUTE

Gavin
Attachment

Re: Clarify libpq docs

From
Peter Eisentraut
Date:
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.)

Re: Clarify libpq docs

From
Tom Lane
Date:
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

Re: Examples for PREPARE/EXECUTE docs

From
Neil Conway
Date:
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

Re: Clarify libpq docs

From
Peter Eisentraut
Date:
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.

Re: Clarify libpq docs

From
Neil Conway
Date:
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