Re: Couple document fixes

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. +