Re: [HACKERS] Parser bug (?)

"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
>> ... my gripe a few days ago that type char is actually implemented as
>> char(1), or more accurately type bpchar(1).

> That's a feature! Sorry I missed your gripe session, but it apparently
> flew by in the e-mail and I didn't spot it.

I think I sent it to pgsql-sql not the hackers list.

> Do you want to dredge it up again, or did one gripe get you feeling
> better?

No, I'm still unhappy.

Basically, what I'm using "plain char" for is as a poor man's
enumerated type.  I have a lot of fields that have only half a dozen
legal values, and what I do is assign somewhat-mnemonic character
codes to each of the allowed values.  This is compact, easy to process,
and I can examine the raw data at need without straining my tired
brain cells very far to remember what the codes stand for.  (It'd be
even better to have a *real* enumerated-type facility, I suppose,
but this works fine and doesn't take a major amount of work to
implement...)

Only problem is that the fields aren't nearly as compact as I
thought they were.

> As a reminder to others (as I'm sure you are already aware of this, but
> want the feature anyway :), an apparent space savings of 4 bytes (1
> bytes vs 5 bytes) for char vs char(1) is not the 80% savings it appears;

You forgot the 4-byte alignment requirement of char(n).  These things
really take 8 bytes each, not the 1 byte each that several "uvchar"s
in a row would take.

> there is a large per-tuple overhead that pretty much swamps any tiny
> data type.

When you have half a dozen of these per tuple (which I do), it starts
to add up.  Besides, the per-tuple overhead has redeeming social
value --- all those fields have a defensible reason for being there.
A 700% storage overhead with no defensible purpose is harder to
swallow.

> I'm pretty sure that any benefit to a visible "unvarnished char" are
> outweighed by the burden of fully implementing all of the "uvchar"
> support functions. It would need to be entirely transparent when mixed
> with char(), varchar(), and text types, and it probably isn't at the
> moment.

Well, all I really give a darn about is whether I can insert, update,
and select on equality.  (Indeed, since I'm using these as enums,
I have no need whatever for them to be transparently interchangeable
with char-string types.  However, I do want them to display as "char"
and not "int1", since small integer codes would lose the mnemonic
aspect...)  A quick look at pg_operator.h indicates that char is
reasonably well supplied with functions, anyway.

Once I found out that I could get to "uvchar" with this little quoting
hack, I satisfied myself that it does everything I need done.  But I
don't care for relying on what is presumably just a parser bug to get
at a fundamental data type.

I didn't object to removing char2, char4, and the other fixed-width
special character types, but I think that plain char has applications
that justify leaving it in there.  I'm willing to consider giving
it a different name if you really insist that char should be char(1)
(though I don't agree with that).
        regards, tom lane