Обсуждение: Couple document fixes
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
Вложения
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
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
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
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
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
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. +
Removing CC to pg-docs so that Robert reads it. Excerpts from Bruce Momjian's message of vie mar 11 08:13:20 -0300 2011: > Kevin Grittner wrote: > > 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. One idea is to rename the type to something else. We could keep "char" as an alias for backwards compatibility, but use the new name in system catalogs, and document it as the main name of the type. Discussed the idea a bit on IM with Bruce, but couldn't find any really good alternative. Idea floated so far: * byte (seems pretty decent to me) * octet (though maybe people would expect it'd output as a number) * char1 (looks ugly, but then we have int4 and so on) * achar (this one is just plain weird) None seems great. Thoughts? -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
> One idea is to rename the type to something else. We could keep "char"
> as an alias for backwards compatibility, but use the new name in system
> catalogs, and document it as the main name of the type.
We don't have type aliases...
regards, tom lane
Excerpts from Tom Lane's message of vie mar 11 12:40:50 -0300 2011: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > One idea is to rename the type to something else. We could keep "char" > > as an alias for backwards compatibility, but use the new name in system > > catalogs, and document it as the main name of the type. > > We don't have type aliases... I meant the conversion we do from a certain name (say because it's the SQL-mandated name for the type) to the internal name, such as mapping integer to int4. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Tom Lane's message of vie mar 11 12:40:50 -0300 2011:
>> Alvaro Herrera <alvherre@commandprompt.com> writes:
>>> One idea is to rename the type to something else. We could keep "char"
>>> as an alias for backwards compatibility, but use the new name in system
>>> catalogs, and document it as the main name of the type.
>> We don't have type aliases...
> I meant the conversion we do from a certain name (say because it's the
> SQL-mandated name for the type) to the internal name, such as mapping
> integer to int4.
That works for keywords. "char" is, by definition, not a keyword.
regards, tom lane
Excerpts from Tom Lane's message of vie mar 11 13:01:06 -0300 2011: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > Excerpts from Tom Lane's message of vie mar 11 12:40:50 -0300 2011: > >> Alvaro Herrera <alvherre@commandprompt.com> writes: > >>> One idea is to rename the type to something else. We could keep "char" > >>> as an alias for backwards compatibility, but use the new name in system > >>> catalogs, and document it as the main name of the type. > > >> We don't have type aliases... > > > I meant the conversion we do from a certain name (say because it's the > > SQL-mandated name for the type) to the internal name, such as mapping > > integer to int4. > > That works for keywords. "char" is, by definition, not a keyword. Oh. Right, of course. Seems the only option is to continue living with it. (Well actually the other option would be to rename it and break backwards compatibility. I'm not sure anyone is going to be happy with that though.) -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > Removing CC to pg-docs so that Robert reads it. > > Excerpts from Bruce Momjian's message of vie mar 11 08:13:20 -0300 2011: > > Kevin Grittner wrote: > > > > 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. > > One idea is to rename the type to something else. We could keep "char" > as an alias for backwards compatibility, but use the new name in system > catalogs, and document it as the main name of the type. > > Discussed the idea a bit on IM with Bruce, but couldn't find any really > good alternative. Idea floated so far: > > * byte (seems pretty decent to me) > * octet (though maybe people would expect it'd output as a number) > * char1 (looks ugly, but then we have int4 and so on) > * achar (this one is just plain weird) > > None seems great. Thoughts? Any new ideas on how to document our "char" data type? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Excerpts from Bruce Momjian's message of lun sep 05 15:21:46 -0300 2011: > Alvaro Herrera wrote: > > Discussed the idea a bit on IM with Bruce, but couldn't find any really > > good alternative. Idea floated so far: > > > > * byte (seems pretty decent to me) > > * octet (though maybe people would expect it'd output as a number) > > * char1 (looks ugly, but then we have int4 and so on) > > * achar (this one is just plain weird) > > > > None seems great. Thoughts? > > Any new ideas on how to document our "char" data type? I think part of the problem is that this only seems to bother patch developers, and only until they become aware of the issue. After that, it just becomes a known gotcha that's easy to work around. Thus, there's not much interest in spending a lot of time fixing it. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Mon, Sep 05, 2011 at 02:21:46PM -0400, Bruce Momjian wrote: > Alvaro Herrera wrote: > > Removing CC to pg-docs so that Robert reads it. > > > > Excerpts from Bruce Momjian's message of vie mar 11 08:13:20 -0300 2011: > > > Kevin Grittner wrote: > > > > > > 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. > > > > One idea is to rename the type to something else. We could keep > > "char" as an alias for backwards compatibility, but use the new > > name in system catalogs, and document it as the main name of the > > type. > > > > Discussed the idea a bit on IM with Bruce, but couldn't find any > > really good alternative. Idea floated so far: > > > > * byte (seems pretty decent to me) * octet (though maybe people > > would expect it'd output as a number) * char1 (looks ugly, but > > then we have int4 and so on) * achar (this one is just plain > > weird) > > > > None seems great. Thoughts? > > Any new ideas on how to document our "char" data type? What say we document it as deprecated and remove the silly thing over the next three releases or so? It's deep in the realm of micro-optimization, and of a kind we well and truly don't need any more, assuming we ever did. Alternate proposals would involve a more aggressive deprecation and removal schedule. ;) Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter wrote: > > > > 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. > > > > > > One idea is to rename the type to something else. We could keep > > > "char" as an alias for backwards compatibility, but use the new > > > name in system catalogs, and document it as the main name of the > > > type. > > > > > > Discussed the idea a bit on IM with Bruce, but couldn't find any > > > really good alternative. Idea floated so far: > > > > > > * byte (seems pretty decent to me) * octet (though maybe people > > > would expect it'd output as a number) * char1 (looks ugly, but > > > then we have int4 and so on) * achar (this one is just plain > > > weird) > > > > > > None seems great. Thoughts? > > > > Any new ideas on how to document our "char" data type? > > What say we document it as deprecated and remove the silly thing over > the next three releases or so? It's deep in the realm of > micro-optimization, and of a kind we well and truly don't need any > more, assuming we ever did. > > Alternate proposals would involve a more aggressive deprecation and > removal schedule. ;) Uh, pg_class uses it: relpersistence | "char" | not nullrelkind | "char" | not null -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Mon, Sep 05, 2011 at 07:33:09PM -0400, Bruce Momjian wrote:
> David Fetter wrote:
> > > > > 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.
> > > >
> > > > One idea is to rename the type to something else. We could keep
> > > > "char" as an alias for backwards compatibility, but use the new
> > > > name in system catalogs, and document it as the main name of the
> > > > type.
> > > >
> > > > Discussed the idea a bit on IM with Bruce, but couldn't find any
> > > > really good alternative. Idea floated so far:
> > > >
> > > > * byte (seems pretty decent to me) * octet (though maybe people
> > > > would expect it'd output as a number) * char1 (looks ugly, but
> > > > then we have int4 and so on) * achar (this one is just plain
> > > > weird)
> > > >
> > > > None seems great. Thoughts?
> > >
> > > Any new ideas on how to document our "char" data type?
> >
> > What say we document it as deprecated and remove the silly thing over
> > the next three releases or so? It's deep in the realm of
> > micro-optimization, and of a kind we well and truly don't need any
> > more, assuming we ever did.
> >
> > Alternate proposals would involve a more aggressive deprecation and
> > removal schedule. ;)
>
> Uh, pg_class uses it:
>
> relpersistence | "char" | not null
> relkind | "char" | not null
>
Interesting. :)
Now that you mention it...
SELECT table_schema, table_name, column_name
FROM information_schema.columns
WHERE data_type = '"char"';table_schema | table_name | column_name
--------------+----------------+---------------pg_catalog | pg_proc | provolatilepg_catalog | pg_type
|typtypepg_catalog | pg_type | typcategorypg_catalog | pg_type | typdelimpg_catalog | pg_type
| typalignpg_catalog | pg_type | typstoragepg_catalog | pg_attribute | attstoragepg_catalog |
pg_attribute | attalignpg_catalog | pg_class | relkindpg_catalog | pg_constraint | contypepg_catalog |
pg_constraint | confupdtypepg_catalog | pg_constraint | confdeltypepg_catalog | pg_constraint |
confmatchtypepg_catalog | pg_operator | oprkindpg_catalog | pg_rewrite | ev_typepg_catalog | pg_rewrite
|ev_enabledpg_catalog | pg_trigger | tgenabledpg_catalog | pg_cast | castcontextpg_catalog | pg_cast
| castmethodpg_catalog | pg_depend | deptypepg_catalog | pg_shdepend | deptypepg_catalog |
pg_default_acl| defaclobjtype
(22 rows)
On brief inspection, it appears that each of these would be better
served, at least functionally, with some kind of enumerated type.
Might it be worth trying to micro-optimize this case for a one-byte
enum? Or maybe something like the varvarlena pattern?
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
Excerpts from David Fetter's message of lun sep 05 21:05:10 -0300 2011: > On brief inspection, it appears that each of these would be better > served, at least functionally, with some kind of enumerated type. > Might it be worth trying to micro-optimize this case for a one-byte > enum? Or maybe something like the varvarlena pattern? What would be the point? It works pretty well already. It doesn't need fixing. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Mon, Sep 05, 2011 at 10:07:29PM -0300, Alvaro Herrera wrote: > Excerpts from David Fetter's message of lun sep 05 21:05:10 -0300 2011: > > > On brief inspection, it appears that each of these would be better > > served, at least functionally, with some kind of enumerated type. > > Might it be worth trying to micro-optimize this case for a one-byte > > enum? Or maybe something like the varvarlena pattern? > > What would be the point? Removing the legacy "char" type, per original post. :) > It works pretty well already. It doesn't need fixing. We've made changes as big on aesthetic grounds before, and if the change results in an enum type optimized for space efficiency, that's all to the good. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
David Fetter <david@fetter.org> writes:
> On Mon, Sep 05, 2011 at 10:07:29PM -0300, Alvaro Herrera wrote:
>> What would be the point?
> Removing the legacy "char" type, per original post. :)
Removing it is the wrong solution.
The idea of renaming it to char1 might be an appropriate balance of pain
versus benefit. Or perhaps not; I'd want to see a proposed patch before
committing to doing anything here.
> We've made changes as big on aesthetic grounds before, and if the
> change results in an enum type optimized for space efficiency, that's
> all to the good.
That's a pipe dream. You can't use enums in catalogs that underlie the
enum implementation. Possibly you could kluge something so that there
are phony entries in pg_enum reflecting the hard-wired values that the C
code uses, but I entirely fail to see any point in such a thing.
regards, tom lane