On Oct 23, Mike Mascari mentioned:

The following patch extends the COMMENT ON functionality to the
rest of the database objects beyond just tables, columns, and views. The
grammer of the COMMENT ON statement now looks like:

COMMENT ON [
[ DATABASE | INDEX | RULE | SEQUENCE | TABLE | TYPE | VIEW ] <objname> |

COLUMN <relation>.<attribute> |
AGGREGATE <aggname> <aggtype> |
FUNCTION <funcname> (arg1, arg2, ...) |
OPERATOR <op> (leftoperand_typ rightoperand_typ) |
TRIGGER <triggername> ON relname>
] IS 'text'
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.

Just to confirm a few things here: Are you keying rule comments on
pg_rewrite.oid? Are operator comments keyed on the oid of the underlying
function? (Perhaps that could even be changed so you can put a comment on
the operator and a note like "implementation of %^*& operator" on the
function. Just a thought.)

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?

-Peter

--
Peter Eisentraut Sernanders vaeg 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

Search Discussions

  • Mike Mascari at Oct 24, 1999 at 9:51 pm
    --- Peter Eisentraut wrote:
    ...
    Just to confirm a few things here: Are you keying rule comments on
    pg_rewrite.oid? Are operator comments keyed on the oid of the underlying
    function? (Perhaps that could even be changed so you can put a comment
    on
    the operator and a note like "implementation of %^*& operator" on the
    function. Just a thought.)

    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?
    ...
    Hmm, this is where I'm getting the oid's:

    DATABASE -- pg_database
    INDEX -- pg_class
    RULE -- pg_rewrite
    SEQUENCE -- pg_class
    TABLE -- pg_class
    TYPE -- pg_type
    VIEW -- pg_class
    COLUMN -- pg_attribute
    AGGREGATE -- pg_aggregate
    FUNCTION -- pg_proc
    OPERATOR -- pg_operator
    TRIGGER -- pg_trigger

    So in the example you gave above, you could put a comment
    on each of the two functions which compose the operator
    and a command on the operator itself.

    I still need to write the SGML and change pg_dump to
    generate COMMENT ON statements, and also regression tests,
    but the functionality should be complete. Just glancing
    over the Win32 ODBC driver, it appears that SQLTables() and
    SQLColumns() is not currently fetching the associated
    description from pg_description for the REMARKS parameter
    to the call. Perhaps this could be changed?

    Hope that helps,

    Mike Mascari (looking forward to the new psql...)
    (mascarim@yahoo.com)




    =====

    __________________________________________________
    Do You Yahoo!?
    Bid and sell for free at http://auctions.yahoo.com
  • Byron Nikolaidis at Oct 25, 1999 at 1:19 am

    Mike Mascari wrote:

    --- Peter Eisentraut wrote:
    ...
    Just to confirm a few things here: Are you keying rule comments on
    pg_rewrite.oid? Are operator comments keyed on the oid of the underlying
    function? (Perhaps that could even be changed so you can put a comment
    on
    the operator and a note like "implementation of %^*& operator" on the
    function. Just a thought.)

    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?
    ...
    Hmm, this is where I'm getting the oid's:

    DATABASE -- pg_database
    INDEX -- pg_class
    RULE -- pg_rewrite
    SEQUENCE -- pg_class
    TABLE -- pg_class
    TYPE -- pg_type
    VIEW -- pg_class
    COLUMN -- pg_attribute
    AGGREGATE -- pg_aggregate
    FUNCTION -- pg_proc
    OPERATOR -- pg_operator
    TRIGGER -- pg_trigger

    So in the example you gave above, you could put a comment
    on each of the two functions which compose the operator
    and a command on the operator itself.

    I still need to write the SGML and change pg_dump to
    generate COMMENT ON statements, and also regression tests,
    but the functionality should be complete. Just glancing
    over the Win32 ODBC driver, it appears that SQLTables() and
    SQLColumns() is not currently fetching the associated
    description from pg_description for the REMARKS parameter
    to the call. Perhaps this could be changed?

    Hope that helps,

    Mike Mascari (looking forward to the new psql...)
    (mascarim@yahoo.com)

    =====

    __________________________________________________
    Do You Yahoo!?
    Bid and sell for free at http://auctions.yahoo.com

    It wouldn't be hard to add the pg_description to the remarks.
    Does this field exist for all previous postgres releases (specifically,
    6.2,6.3, and 6.4) ??

    Byron
  • Peter Eisentraut at Oct 25, 1999 at 8:49 am

    On Sun, 24 Oct 1999, Mike Mascari wrote:

    Hmm, this is where I'm getting the oid's:

    DATABASE -- pg_database
    INDEX -- pg_class
    RULE -- pg_rewrite
    SEQUENCE -- pg_class
    TABLE -- pg_class
    TYPE -- pg_type
    VIEW -- pg_class
    COLUMN -- pg_attribute
    AGGREGATE -- pg_aggregate
    FUNCTION -- pg_proc
    OPERATOR -- pg_operator
    TRIGGER -- pg_trigger

    So in the example you gave above, you could put a comment
    on each of the two functions which compose the operator
    and a command on the operator itself.
    Very nice, BUT: In the old psql the assumption was that operator comments
    are keyed on the underlying function(s?). Since a lot of operators seem to
    have comments on them by default, one would have to change this somehow.
    Try \do and see for yourself. The fix should be rather simple but I'm not
    sure where those descriptions are generated actually.

    -Peter

    --
    Peter Eisentraut Sernanders vaeg 10:115
    peter_e@gmx.net 75262 Uppsala
    http://yi.org/peter-e/ Sweden
  • Tom Lane at Oct 25, 1999 at 3:02 pm

    Peter Eisentraut writes:
    On Sun, 24 Oct 1999, Mike Mascari wrote:
    So in the example you gave above, you could put a comment
    on each of the two functions which compose the operator
    and a command on the operator itself.
    Two functions? An operator only has one underlying function.
    (Aggregates have as many as three though.)
    Try \do and see for yourself. The fix should be rather simple but I'm not
    sure where those descriptions are generated actually.
    The default contents of pg_description come from the DESCR() macros in
    include/catalog/*.h. It looks like only pg_proc and pg_type have any
    useful info in them in the current state of the source. I'm guessing
    that psql's \do actually looks for a description attached to the
    underlying function, rather than one attached to the operator.

    regards, tom lane
  • Bruce Momjian at Oct 26, 1999 at 5:04 am

    Peter Eisentraut writes:
    On Sun, 24 Oct 1999, Mike Mascari wrote:
    So in the example you gave above, you could put a comment
    on each of the two functions which compose the operator
    and a command on the operator itself.
    Two functions? An operator only has one underlying function.
    (Aggregates have as many as three though.)
    Try \do and see for yourself. The fix should be rather simple but I'm not
    sure where those descriptions are generated actually.
    The default contents of pg_description come from the DESCR() macros in
    include/catalog/*.h. It looks like only pg_proc and pg_type have any
    useful info in them in the current state of the source. I'm guessing
    that psql's \do actually looks for a description attached to the
    underlying function, rather than one attached to the operator.
    I can only get oids that are fixed in the include files. Not sure if it
    looks at the function behind the operator. I just don't remember.

    --
    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, Pennsylvania 19026
  • Bruce Momjian at Oct 26, 1999 at 5:03 am

    Hmm, this is where I'm getting the oid's:

    DATABASE -- pg_database
    INDEX -- pg_class
    RULE -- pg_rewrite
    SEQUENCE -- pg_class
    TABLE -- pg_class
    TYPE -- pg_type
    VIEW -- pg_class
    COLUMN -- pg_attribute
    AGGREGATE -- pg_aggregate
    FUNCTION -- pg_proc
    OPERATOR -- pg_operator
    TRIGGER -- pg_trigger

    So in the example you gave above, you could put a comment
    on each of the two functions which compose the operator
    and a command on the operator itself.

    I still need to write the SGML and change pg_dump to
    Please update the sgml and psqlHelp.c files I have already modified for
    you. I thought you didn't want to do it, so I did it.

    generate COMMENT ON statements, and also regression tests,
    but the functionality should be complete. Just glancing
    over the Win32 ODBC driver, it appears that SQLTables() and
    SQLColumns() is not currently fetching the associated
    description from pg_description for the REMARKS parameter
    to the call. Perhaps this could be changed?
    Hmm. Never heard of that.

    --
    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, Pennsylvania 19026
  • Mike Mascari at Oct 25, 1999 at 5:14 am
    --- Byron Nikolaidis wrote:
    ...
    I still need to write the SGML and change pg_dump to
    generate COMMENT ON statements, and also regression tests,
    but the functionality should be complete. Just glancing
    over the Win32 ODBC driver, it appears that SQLTables() and
    SQLColumns() is not currently fetching the associated
    description from pg_description for the REMARKS parameter
    to the call. Perhaps this could be changed?
    It wouldn't be hard to add the pg_description to the remarks.
    Does this field exist for all previous postgres releases (specifically,
    6.2,6.3, and 6.4) ??

    Byron
    ...

    It appears, just from a spot check of the initial database structure
    created from old RPMS on rpmfind.net that pg_description was added
    after 6.2 whose "provides" looks like this (for 6.2.1):

    ...
    /var/lib/postgresql/data/base/template1/pg_attrdefind
    /var/lib/postgresql/data/base/template1/pg_attrelidind
    /var/lib/postgresql/data/base/template1/pg_attribute
    /var/lib/postgresql/data/base/template1/pg_class
    /var/lib/postgresql/data/base/template1/pg_classnameind
    /var/lib/postgresql/data/base/template1/pg_classoidind
    /var/lib/postgresql/data/base/template1/pg_index
    /var/lib/postgresql/data/base/template1/pg_inheritproc
    /var/lib/postgresql/data/base/template1/pg_inherits
    /var/lib/postgresql/data/base/template1/pg_internal.init
    ...

    while for 6.3.1, the initial database structure looks like:

    ...
    /var/lib/pgsql/base/template1/pg_class
    /var/lib/pgsql/base/template1/pg_class_oid_index
    /var/lib/pgsql/base/template1/pg_class_relname_index
    /var/lib/pgsql/base/template1/pg_description
    /var/lib/pgsql/base/template1/pg_description_objoid_index
    /var/lib/pgsql/base/template1/pg_index
    /var/lib/pgsql/base/template1/pg_inheritproc
    ...

    And of course, it appears also in 6.4.x, so I assume that it was added
    between the 6.2 and 6.3 releases. Is that going to be a problem?

    Hope that helps,

    Mike Mascari
    (mascarim@yahoo.com)










    __________________________________________________
    Do You Yahoo!?
    Bid and sell for free at http://auctions.yahoo.com
  • Tom Lane at Oct 25, 1999 at 5:37 am

    Mike Mascari writes:
    Does this field exist for all previous postgres releases (specifically,
    6.2,6.3, and 6.4) ??
    And of course, it appears also in 6.4.x, so I assume that it was added
    between the 6.2 and 6.3 releases. Is that going to be a problem?
    For Peter's purposes, it's unnecessary to worry about anything older
    than 6.4, since he's depending on an up-to-date libpq and current libpq
    won't talk to anything older than 6.4.

    Byron might still care about 6.2 ... I dunno whether ODBC currently
    really works with 6.2 or not, or whether it needs to keep doing so.

    regards, tom lane
  • Byron Nikolaidis at Oct 25, 1999 at 11:46 pm

    Tom Lane wrote:

    Mike Mascari <mascarim@yahoo.com> writes:
    Does this field exist for all previous postgres releases (specifically,
    6.2,6.3, and 6.4) ??
    And of course, it appears also in 6.4.x, so I assume that it was added
    between the 6.2 and 6.3 releases. Is that going to be a problem?
    For Peter's purposes, it's unnecessary to worry about anything older
    than 6.4, since he's depending on an up-to-date libpq and current libpq
    won't talk to anything older than 6.4.

    Byron might still care about 6.2 ... I dunno whether ODBC currently
    really works with 6.2 or not, or whether it needs to keep doing so.

    regards, tom lane

    It still really works with 6.2! But whether it needs to, is another
    question!

    I'm not sure if anyone cares if it works with 6.2 (even 6.3 for that
    matter) or not.

    Byron
  • Bruce Momjian at Oct 26, 1999 at 5:03 am

    --- Byron Nikolaidis wrote:
    ...
    I still need to write the SGML and change pg_dump to
    generate COMMENT ON statements, and also regression tests,
    but the functionality should be complete. Just glancing
    over the Win32 ODBC driver, it appears that SQLTables() and
    SQLColumns() is not currently fetching the associated
    description from pg_description for the REMARKS parameter
    to the call. Perhaps this could be changed?
    It wouldn't be hard to add the pg_description to the remarks.
    Does this field exist for all previous postgres releases (specifically,
    6.2,6.3, and 6.4) ??
    HISTORY file says added in release 6.3.


    --
    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, Pennsylvania 19026
  • Mike Mascari at Oct 25, 1999 at 5:14 am
    --- Byron Nikolaidis wrote:
    ...
    I still need to write the SGML and change pg_dump to
    generate COMMENT ON statements, and also regression tests,
    but the functionality should be complete. Just glancing
    over the Win32 ODBC driver, it appears that SQLTables() and
    SQLColumns() is not currently fetching the associated
    description from pg_description for the REMARKS parameter
    to the call. Perhaps this could be changed?
    It wouldn't be hard to add the pg_description to the remarks.
    Does this field exist for all previous postgres releases (specifically,
    6.2,6.3, and 6.4) ??

    Byron
    ...

    It appears, just from a spot check of the initial database structure
    created from old RPMS on rpmfind.net that pg_description was added
    after 6.2 whose "provides" looks like this (for 6.2.1):

    ...
    /var/lib/postgresql/data/base/template1/pg_attrdefind
    /var/lib/postgresql/data/base/template1/pg_attrelidind
    /var/lib/postgresql/data/base/template1/pg_attribute
    /var/lib/postgresql/data/base/template1/pg_class
    /var/lib/postgresql/data/base/template1/pg_classnameind
    /var/lib/postgresql/data/base/template1/pg_classoidind
    /var/lib/postgresql/data/base/template1/pg_index
    /var/lib/postgresql/data/base/template1/pg_inheritproc
    /var/lib/postgresql/data/base/template1/pg_inherits
    /var/lib/postgresql/data/base/template1/pg_internal.init
    ...

    while for 6.3.1, the initial database structure looks like:

    ...
    /var/lib/pgsql/base/template1/pg_class
    /var/lib/pgsql/base/template1/pg_class_oid_index
    /var/lib/pgsql/base/template1/pg_class_relname_index
    /var/lib/pgsql/base/template1/pg_description
    /var/lib/pgsql/base/template1/pg_description_objoid_index
    /var/lib/pgsql/base/template1/pg_index
    /var/lib/pgsql/base/template1/pg_inheritproc
    ...

    And of course, it appears also in 6.4.x, so I assume that it was added
    between the 6.2 and 6.3 releases. Is that going to be a problem?

    Hope that helps,

    Mike Mascari
    (mascarim@yahoo.com)



    =====

    __________________________________________________
    Do You Yahoo!?
    Bid and sell for free at http://auctions.yahoo.com
  • Mike Mascari at Oct 25, 1999 at 7:26 pm

    --- Tom Lane wrote:
    Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
    On Sun, 24 Oct 1999, Mike Mascari wrote:
    So in the example you gave above, you could put a comment
    on each of the two functions which compose the operator
    and a command on the operator itself.
    Two functions? An operator only has one underlying function.
    (Aggregates have as many as three though.)
    I'm sorry...it was late a night. I meant you could comment on left
    and right hand sides of the operator (the types) as well as the function
    and also on the operator itself. I also spelled comment as command)...
    Try \do and see for yourself. The fix should be rather simple but I'm not
    sure where those descriptions are generated actually.
    The default contents of pg_description come from the DESCR() macros in
    include/catalog/*.h. It looks like only pg_proc and pg_type have any
    useful info in them in the current state of the source. I'm guessing
    that psql's \do actually looks for a description attached to the
    underlying function, rather than one attached to the operator.
    Perhaps this behavior should continue. But I thought it would be
    nice to comment on the function of the operator without respect to the
    function.

    Mike Mascari
    (mascarim@yahoo.com)







    =====

    __________________________________________________
    Do You Yahoo!?
    Bid and sell for free at http://auctions.yahoo.com
  • Bruce Momjian at Oct 26, 1999 at 4:39 am

    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, Pennsylvania 19026
  • Peter Eisentraut at Oct 26, 1999 at 11:33 am

    On Tue, 26 Oct 1999, Bruce Momjian wrote:

    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.
    I implemented sort of shell variables into psql (I mentioned it in the
    changelogs, but those were admittedly quite long), so you can set
    variables like:
    \set foo 'bar'
    \echo $foo
    \echo "foo is now ${foo}"
    etc.

    The initial motivation was that I would run out of mnemonic flags pretty
    soon, so most psql state is now in a variable:
    \set quiet on (-q switch)
    \set echo on (-e switch)
    \set echo_secret on (-E switch)
    etc.
    (In fact you don't have to set them to "on", anything works. To unset them
    just write \set varname)
    The cmd line switches are unaffected, but this way you can also set them
    within psql. There are also a few variables representing new
    functionality:
    \set description on
    will turn on the display of the object descriptions. There are a few
    others, too.

    That's just what I meant with the above. Of course one fine day very soon
    I'll formally document all of this in DocBook. There is _a lot_ of new
    stuff, so I might actually end up doing a lot of new documenting. You
    might want to save yourself the work right now.

    -Peter

    --
    Peter Eisentraut Sernanders vaeg 10:115
    peter_e@gmx.net 75262 Uppsala
    http://yi.org/peter-e/ Sweden

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedOct 24, '99 at 7:49p
activeOct 26, '99 at 11:33a
posts15
users6
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase