Re: [HACKERS] [PATCHES] DOC: catalog.sgml
Zdenek Kotala wrote: Alvaro Herrera wrote: What's global? A maybe-useful flag would be telling that a table is shared. Is that it? Mind you, it's not useful to me because I know which tables are shared, but I guess for someone not so familiar with the catalogs it could have some use. Global means share table stored in global directory :-). Ok I change it. There is new version of catalogs overview patch. This version add only one column into overview table which contains Oid/Filename for each catalog table. Oid information is important if someone need make relation with filename on disk and related catalog table. In this column shared table are marked as well. Other information like bootstrap and with-oids are really useless and they is not mentioned. Zdenek Index: doc/src/sgml/catalogs.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/catalogs.sgml,v retrieving revision 2.134 diff -c -r2.134 catalogs.sgml *** doc/src/sgml/catalogs.sgml 22 Sep 2006 23:20:13 - 2.134 --- doc/src/sgml/catalogs.sgml 4 Oct 2006 12:17:49 - *** *** 33,47 Most system catalogs are copied from the template database during database creation and are thereafter database-specific. A few catalogs are physically shared across all databases in a cluster; !these are noted in the descriptions of the individual catalogs. /para table id=catalog-table titleSystem Catalogs/title !tgroup cols=2 thead row entryCatalog Name/entry entryPurpose/entry /row --- 33,49 Most system catalogs are copied from the template database during database creation and are thereafter database-specific. A few catalogs are physically shared across all databases in a cluster; !these are noted in the Oid/Filename column and in the descriptions !of the individual catalogs. /para table id=catalog-table titleSystem Catalogs/title !tgroup cols=3 thead row + entryOid/Filename/entry entryCatalog Name/entry entryPurpose/entry /row *** *** 49,214 --- 51,249 tbody row + entry2600/entry entrylink linkend=catalog-pg-aggregatestructnamepg_aggregate/structname/link/entry entryaggregate functions/entry /row row + entry2601/entry entrylink linkend=catalog-pg-amstructnamepg_am/structname/link/entry entryindex access methods/entry /row row + entry2602/entry entrylink linkend=catalog-pg-amopstructnamepg_amop/structname/link/entry entryaccess method operators/entry /row row + entry2603/entry entrylink linkend=catalog-pg-amprocstructnamepg_amproc/structname/link/entry entryaccess method support procedures/entry /row row + entry2604/entry entrylink linkend=catalog-pg-attrdefstructnamepg_attrdef/structname/link/entry entrycolumn default values/entry /row row + entry1249/entry entrylink linkend=catalog-pg-attributestructnamepg_attribute/structname/link/entry entrytable columns (quoteattributes/quote)/entry /row row + entry1260 (shared)/entry entrylink linkend=catalog-pg-authidstructnamepg_authid/structname/link/entry entryauthorization identifiers (roles)/entry /row row + entry1261 (shared)/entry entrylink linkend=catalog-pg-auth-membersstructnamepg_auth_members/structname/link/entry entryauthorization identifier membership relationships/entry /row row + entry1248/entry entrylink linkend=catalog-pg-autovacuumstructnamepg_autovacuum/structname/link/entry entryper-relation autovacuum configuration parameters/entry /row row + entry2605/entry entrylink linkend=catalog-pg-caststructnamepg_cast/structname/link/entry entrycasts (data type conversions)/entry /row row + entry1259/entry entrylink linkend=catalog-pg-classstructnamepg_class/structname/link/entry entrytables, indexes, sequences, views (quoterelations/quote)/entry /row row + entry2606/entry entrylink linkend=catalog-pg-constraintstructnamepg_constraint/structname/link/entry entrycheck constraints, unique constraints, primary key constraints, foreign key constraints/entry /row row + entry2607/entry entrylink linkend=catalog-pg-conversionstructnamepg_conversion/structname/link/entry entryencoding conversion information/entry /row row + entry1262 (shared)/entry entrylink linkend=catalog-pg-databasestructnamepg_database/structname/link/entry entrydatabases within this database cluster/entry
Re: [HACKERS] [PATCHES] DOC: catalog.sgml
Zdenek Kotala [EMAIL PROTECTED] writes: There is new version of catalogs overview patch. This version add only one column into overview table which contains Oid/Filename for each catalog table. Oid information is important if someone need make relation with filename on disk and related catalog table. I still say this is just confusing clutter. The proposed patch even goes so far as to give the OID pride of place as the most important item you could possibly want to know about a catalog, which is surely silly. People who actually want to know this information can look into the pg_class catalog, which has the advantages of being complete (eg, it covers indexes too), guaranteed up-to-date, and easily program-readable. I really do not see the value of putting it in the sgml docs. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [PATCHES] DOC: catalog.sgml
Tom Lane wrote: Zdenek Kotala [EMAIL PROTECTED] writes: There is new version of catalogs overview patch. This version add only one column into overview table which contains Oid/Filename for each catalog table. Oid information is important if someone need make relation with filename on disk and related catalog table. I still say this is just confusing clutter. The proposed patch even goes so far as to give the OID pride of place as the most important item you could possibly want to know about a catalog, which is surely silly. You have right that OID is not important information in many cases, but how I said It is useful when you want know relation between filename and catalog table. People who actually want to know this information can look into the pg_class catalog, which has the advantages of being complete (eg, it covers indexes too), guaranteed up-to-date, and easily program-readable. I really do not see the value of putting it in the sgml docs. You can look into pg_class catalog only if database is running. If you have some data corruption problem, OID should help during recovery. But you have right, that pg_class have complex information and who want to play with datafiles, he must know more than OID. OK, thanks for response, forget to this patch Zdenek ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] DOC: catalog.sgml
Tom Lane napsal(a): Zdenek Kotala [EMAIL PROTECTED] writes: I little bit enhanced overview catalog tables. I added two new columns. First one is OID of catalog table and second one contains attributes which determine if the table is bootstrap, with oid and global. Why is this a good idea? It seems like mere clutter. I'm working on pg_upgrade and these information are important for me and I think that They should be interest some else. You can easy determine the file related to if you know the OID. Specially when database is shutdown is good to have some information source. If catalog table is global/share or local is very important and it is not mentioned anywhere. If it is created with oid or bootstrap it is not important for standard purpose, it is only for fullness. I know that people who hacking postgres ten years know this, however it is internals chapter and for newbies it should be useful. And by the way it is documentation and this is completion of information. You can say why we have page layout there because it is described in the source code and so on... Zdenek ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] DOC: catalog.sgml
Alvaro Herrera wrote: Tom Lane wrote: Zdenek Kotala [EMAIL PROTECTED] writes: I little bit enhanced overview catalog tables. I added two new columns. First one is OID of catalog table and second one contains attributes which determine if the table is bootstrap, with oid and global. Why is this a good idea? It seems like mere clutter. What's global? A maybe-useful flag would be telling that a table is shared. Is that it? Mind you, it's not useful to me because I know which tables are shared, but I guess for someone not so familiar with the catalogs it could have some use. Global means share table stored in global directory :-). Ok I change it. Thanks for comment Zdenek ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] DOC: catalog.sgml
On Sun, Sep 03, 2006 at 12:01:06AM -0400, Tom Lane wrote: But ever since 7.3 the convention for identifying system objects has been pretty well-defined: anything that lives in one of the predefined schemas. What problem were you having using that approach in newsysviews? It was just an issue of trawling through pg_dump to confirm that. -- Jim C. Nasby, Database Architect [EMAIL PROTECTED] 512.569.9461 (cell) http://jim.nasby.net ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] DOC: catalog.sgml
On Fri, Sep 01, 2006 at 12:36:11PM -0400, Alvaro Herrera wrote: Tom Lane wrote: Zdenek Kotala [EMAIL PROTECTED] writes: I little bit enhanced overview catalog tables. I added two new columns. First one is OID of catalog table and second one contains attributes which determine if the table is bootstrap, with oid and global. Why is this a good idea? It seems like mere clutter. What's global? A maybe-useful flag would be telling that a table is shared. Is that it? Mind you, it's not useful to me because I know which tables are shared, but I guess for someone not so familiar with the catalogs it could have some use. The OIDs may be useful to people inspecting pg_depend, for example; but then, it's foolish not to be using regclass in that case. Whether a table is bootstrap or not doesn't seem useful to me. Something that might be handy would be a method to determine if an object is a system object or not (perhaps what the OP means by bootstrap). We spent quite some time figuring out how to handle that when we were working on newsysviews. In that case, we wanted the info because it's handy to be able to query a view that's not cluttered up with a bunch of system-defined stuff. Having a way to get a list of only user-defined functions, for example. -- Jim C. Nasby, Database Architect [EMAIL PROTECTED] 512.569.9461 (cell) http://jim.nasby.net ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] DOC: catalog.sgml
Jim C. Nasby [EMAIL PROTECTED] writes: On Fri, Sep 01, 2006 at 12:36:11PM -0400, Alvaro Herrera wrote: Whether a table is bootstrap or not doesn't seem useful to me. Something that might be handy would be a method to determine if an object is a system object or not (perhaps what the OP means by bootstrap). No, what the OP meant by bootstrap is one of the four core BKI_BOOTSTRAP catalogs, and the reason they're so core is that bootstrap mode itself doesn't really work till they exist. (I agree with Alvaro that by the time you get interested in what BKI_BOOTSTRAP does, you probably don't need to have any hand-holding from catalogs.sgml; you're already at least an apprentice wizard.) But ever since 7.3 the convention for identifying system objects has been pretty well-defined: anything that lives in one of the predefined schemas. What problem were you having using that approach in newsysviews? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] DOC: catalog.sgml
Zdenek Kotala [EMAIL PROTECTED] writes: I little bit enhanced overview catalog tables. I added two new columns. First one is OID of catalog table and second one contains attributes which determine if the table is bootstrap, with oid and global. Why is this a good idea? It seems like mere clutter. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [PATCHES] DOC: catalog.sgml
Tom Lane wrote: Zdenek Kotala [EMAIL PROTECTED] writes: I little bit enhanced overview catalog tables. I added two new columns. First one is OID of catalog table and second one contains attributes which determine if the table is bootstrap, with oid and global. Why is this a good idea? It seems like mere clutter. What's global? A maybe-useful flag would be telling that a table is shared. Is that it? Mind you, it's not useful to me because I know which tables are shared, but I guess for someone not so familiar with the catalogs it could have some use. The OIDs may be useful to people inspecting pg_depend, for example; but then, it's foolish not to be using regclass in that case. Whether a table is bootstrap or not doesn't seem useful to me. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
