Re: Couple document fixes

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(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)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