Re: Couple document fixes - Mailing list pgsql-hackers

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