Обсуждение: Couple document fixes

Поиск
Список
Период
Сортировка

Couple document fixes

От
Thom Brown
Дата:
Hi,

I've attached a couple minor fixes to the docs.  One relating to
SECURITY LABEL and the other for pg_class.relpersistence

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

Вложения

Re: [HACKERS] Couple document fixes

От
"Kevin Grittner"
Дата:
Thom Brown <thom@linux.com> wrote:

> I've attached a couple minor fixes to the docs.  One relating to
> SECURITY LABEL and the other for pg_class.relpersistence

relpersistence should be <type>"char"</type>, not <type>char</type>.
Oddly enough, there is a difference.

-Kevin

Re: [HACKERS] Couple document fixes

От
Thom Brown
Дата:
On 19 January 2011 18:11, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote:
> Thom Brown <thom@linux.com> wrote:
>
>> I've attached a couple minor fixes to the docs.  One relating to
>> SECURITY LABEL and the other for pg_class.relpersistence
>
> relpersistence should be <type>"char"</type>, not <type>char</type>.
> Oddly enough, there is a difference.
>
> -Kevin

relkind in the same table is the same type, but isn't displayed as
"char" in the docs, and the same applies to many other system tables.
They would need changing too then.

Examples are:

pg_type.typtype
pg_proc.provolatile
pg_attribute.attstorage

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

Re: [HACKERS] Couple document fixes

От
"Kevin Grittner"
Дата:
Thom Brown <thom@linux.com> wrote:

> relkind in the same table is the same type, but isn't displayed as
> "char" in the docs, and the same applies to many other system
tables.
> They would need changing too then.
>
> Examples are:
>
> pg_type.typtype
> pg_proc.provolatile
> pg_attribute.attstorage

That's a good point.  Consistency would trump getting a single entry
right, for sure.  I wonder, though, whether we shouldn't
consistently distinguish them.  For one thing, I've seen multiple
posts where people were reporting "bugs" because of having confused
char with "char".

FWIW, \d shows:

       Table "pg_catalog.pg_class"
     Column      |   Type    | Modifiers
-----------------+-----------+-----------
 relname         | name      | not null
 relnamespace    | oid       | not null
 reltype         | oid       | not null
 reloftype       | oid       | not null
 relowner        | oid       | not null
 relam           | oid       | not null
 relfilenode     | oid       | not null
 reltablespace   | oid       | not null
 relpages        | integer   | not null
 reltuples       | real      | not null
 reltoastrelid   | oid       | not null
 reltoastidxid   | oid       | not null
 relhasindex     | boolean   | not null
 relisshared     | boolean   | not null
 relpersistence  | "char"    | not null
 relkind         | "char"    | not null
 relnatts        | smallint  | not null
 relchecks       | smallint  | not null
 relhasoids      | boolean   | not null
 relhaspkey      | boolean   | not null
 relhasexclusion | boolean   | not null
 relhasrules     | boolean   | not null
 relhastriggers  | boolean   | not null
 relhassubclass  | boolean   | not null
 relfrozenxid    | xid       | not null
 relacl          | aclitem[] |
 reloptions      | text[]    |
Indexes:
    "pg_class_oid_index" UNIQUE, btree (oid)
    "pg_class_relname_nsp_index" UNIQUE, btree (relname,
relnamespace)

Currently we don't seem to distinguish them in very many places in
the docs:

$ find -name '*.sgml' | xargs egrep -n '\"char\"'
./doc/src/sgml/textsearch.sgml:1271:setweight(<replaceable
class="PARAMETER">vector</replaceable> <type>tsvector</>,
<replaceable class="PARAMETER">weight</replaceable> <type>"char"</>)
returns <type>tsvector</>
./doc/src/sgml/datatype.sgml:1116:    length might change in a
future release. The type <type>"char"</type>
./doc/src/sgml/datatype.sgml:1134:
<entry><type>"char"</type></entry>
./doc/src/sgml/release-old.sgml:4406:Add routines for single-byte
"char" type(Thomas)
./doc/src/sgml/release-old.sgml:4747:Make "char" type a synonym for
"char(1)" (actually implemented as bpchar)(Thomas)
./doc/src/sgml/xfunc.sgml:1794:
<entry><type>"char"</type></entry>
./doc/src/sgml/release-8.0.sgml:3389:      <type>"char"</> data type
have been removed.
./doc/src/sgml/release-8.0.sgml:4460:        <type>"char"</> data
type have been removed.
./doc/src/sgml/release-8.0.sgml:4466:        to do arithmetic on a
<type>"char"</> column, you can cast it to
./doc/src/sgml/func.sgml:8462:
<literal><function>setweight(<type>tsvector</>,
<type>"char"</>)</function></literal>
./doc/src/sgml/btree-gin.sgml:17:  <type>oid</>, <type>money</>,
<type>"char"</>,

-Kevin

Re: [HACKERS] Couple document fixes

От
Tom Lane
Дата:
Thom Brown <thom@linux.com> writes:
> I've attached a couple minor fixes to the docs.  One relating to
> SECURITY LABEL and the other for pg_class.relpersistence

Applied, thanks.

            regards, tom lane

Re: [HACKERS] Couple document fixes

От
Thom Brown
Дата:
On 19 January 2011 21:10, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thom Brown <thom@linux.com> writes:
>> I've attached a couple minor fixes to the docs.  One relating to
>> SECURITY LABEL and the other for pg_class.relpersistence
>
> Applied, thanks.

Cheers Mr Lane.

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

Re: [HACKERS] Couple document fixes

От
Bruce Momjian
Дата:
Kevin Grittner wrote:
> Thom Brown <thom@linux.com> wrote:
>
> > I've attached a couple minor fixes to the docs.  One relating to
> > SECURITY LABEL and the other for pg_class.relpersistence
>
> relpersistence should be <type>"char"</type>, not <type>char</type>.
> Oddly enough, there is a difference.

I am unsure on that one.  We have many 'char' mentions in catalog.sgml,
and I don't see any of them shown as '"char"'.  (Wow, we should have
just called this type char1, but I think that name came from Berkeley!)
The big problem is that the pg_type name is really "char" _without_
quotes.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +