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 <[email protected]> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
