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