Couple document fixes

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 null
relkind | "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 | provolatile
pg_catalog | pg_type | typtype
pg_catalog | pg_type | typcategory
pg_catalog | pg_type | typdelim
pg_catalog | pg_type | typalign
pg_catalog | pg_type | typstorage
pg_catalog | pg_attribute | attstorage
pg_catalog | pg_attribute | attalign
pg_catalog | pg_class | relkind
pg_catalog | pg_constraint | contype
pg_catalog | pg_constraint | confupdtype
pg_catalog | pg_constraint | confdeltype
pg_catalog | pg_constraint | confmatchtype
pg_catalog | pg_operator | oprkind
pg_catalog | pg_rewrite | ev_type
pg_catalog | pg_rewrite | ev_enabled
pg_catalog | pg_trigger | tgenabled
pg_catalog | pg_cast | castcontext
pg_catalog | pg_cast | castmethod
pg_catalog | pg_depend | deptype
pg_catalog | pg_shdepend | deptype
pg_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