> Oh my, that's interesting ... and it looks like it is closely related
> to 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. Do you want to dredge it up
again, or did one gripe get you feeling better?
> So it appears that *something* (probably the parser) is converting the
> unquoted type name char to a bpchar (blank-padded char array),
> but if it's quoted then you actually get the primitive char type.
> Seems to me that that's a bug: if you ask for char, and not char(1),
> you should get char.
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.
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;
there is a large per-tuple overhead that pretty much swamps any tiny
data type.
> The second bug exhibited by Oliver's example is that a literal 'M'
> is not recognized as compatible with the primitive char type.
> That won't do either.
> I tried coercing the 'M' to a char explicitly, just to see what would
> happen, and got a coredump:
> So that's another bug, though possibly unrelated.
We should continue the discussion before I try for a fix, to make sure
that you don't get railroaded into *never* being able to use "uvchar" ;)
- Tom