> In related news I'd like to point out that psql's \dd command now supports
> aggregates, functions, operators, types, relations (tables, views,
> indices, sequences), rules, and triggers. In addition all the other \d?
> commands (\da, \df, \dT, \do, \dtvsiS), as well as \l, have comments
> display switchable. Attribute comments can be seen in \d in a similar
> fashion. You can also give a comment on \lo_import which can then be seen
> in \lo_list (=\dl). Seems like all the bases are covered.
OK, I think we need help on this. I have added documentation in
psqlHelp.c and comment.sgml. You are mentioning some new psql flags
that I don't know we had. Can you send info on that. psql.c and
psql-ref.sgml are two areas that need additions based on what you said.
> Now we just have to stick a whole bunch of comments on all system stuff.
> Where would be a good place to do this? Where are all the comments on the
> built-in operators generated?
OK, right now, comments are in src/include/catalog as DESC entries.
These are pulled out by OID during creation of the *.bki files, and
initdb does a COPY to load the description table.
One limitation now is that we can only comment objects that have a fixed
oid in the system tables because we define the oid at compile time
coming from the system table.
One idea I had in the past was to store the object type and object name
instead in a file during compile, and run some UPDATE during initdb that
looked up the oid of the object type and name, and stuffed that
initdb-supplied oid into the pg_description table. I think that is the
only way you are going to be able to do this properly.
Seems your COMMENT command already has this done. You could just dump a
file containing COMMENT lines as part of *.bki compile process, and have
inintdb run the COMMENT file. That is the best way, I think.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
