From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Parser bug (?) |
Date: | 1998-12-06 05:46:35 |
Message-ID: | 20656.912923195@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Thomas G. Lockhart" <lockhart(at)alumni(dot)caltech(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas G. Lockhart | 1998-12-06 06:46:56 | Re: [HACKERS] Parser bug (?) |
Previous Message | Thomas G. Lockhart | 1998-12-06 03:55:17 | Re: [HACKERS] Parser bug (?) |