Hello Tom,
Here's a more fully fleshed out draft for this, with stylesheet
markup to get extra space around the column type names.
I find this added spacing awkward, espacially as attribute names are
always one word anyway. I prefer the non spaced approach.
It's certainly arguable that
Hello Tom,
Here's a more fully fleshed out draft for this, with stylesheet
markup to get extra space around the column type names.
I find this added spacing awkward, espacially as attribute names are
always one word anyway. I prefer the non spaced approach.
If spacing is discussed,
Hello Tom,
oid OID
Meh. I'm not a fan of overuse of upper case --- it's well established
that that's harder to read than lower or mixed case. And it's definitely
project policy that type names are generally treated as identifiers not
keywords, even if some of them happen to be keywords
Hello Tom,
oid oid
Row identifier
adrelid oid (references pg_class.oid)
The table this column belongs to
adnum int2 (references pg_attribute.attnum)
The number of the column
adbin pg_node_tree
The column default value, in nodeToString() representation. Use
I quite like this suggestion, so I’ve changed the patch to do this. Removed
the doc: in the commit message to indicate that this is no longer just touching
documentation.
About v2: applies cleanly, compiles, make check and doc gen ok.
However, the documentation does not look right, field
Hello Daniel,
I quite like this suggestion, so I’ve changed the patch to do this.
Removed the doc: in the commit message to indicate that this is no
longer just touching documentation.
And it should be posted to .
--
Fabien.
Hello,
To take into account Tom's comment, I'd suggest a middle ground by
commenting a public and private part explicitely in the struct,
typedef struct {
/* PUBLIC members to be used by callers ... */
/* PRIVATE members, not intended for external usage ... */
} ... ;
One
Hello Daniel,
Since this makes the number of internal members far outnumber the public
ones, also reword the statement about which fields can be used to try
and improve clarity.
Patch applies cleanly, doc build ok.
To take into account Tom's comment, I'd suggest a middle ground by
