Re: AW: [HACKERS] varchar() vs char16 performance

>
> > I had thought that char2-16 add _no_ functionality over the char() and
> > varchar() types; Tatsuo points out at least one capability which they
> > have. Are there any others?
> >
> > They give and take a char * pointer to a C function like
> > create function upper(char16)
> > returning char16 as '/u/my/upper.so' language 'sql';
> > whereas char() gives a varlena pointer.
> >
>
> The char[248] types rip out just fine.
>
> But that char16 is a whole new beast.  It's tentacles are everywhere...
>
> >From comments in various files, the char16 was the original name type
> and was then replaced with 'name'.  But there are still a few places
> of inconsistency in the code, namely (*bad pun*) in the cache code.

Yes, you are correct.  That was the original name length.

I thought I fixed all the cache name16 references before 6.3.  That is
why we can now have index names over 16 characters.  Can you confirm
this is still a problem in 6.3.

>
> There is this eqproc array in catcache.c that is a hack that has to
> match the oids of the types from oid 16 to 30, except that F_CHAR16EQ
> is still where F_NAMEEQ should be.  Tried renaming it last night, but
> initdb would blowup the first insert, so there is some other effect in
> the caching code.
>
> Still other incomplete conversions.  In pg_proc.h the arg types for
> char16eq, lt, le, gt, ge & ne are names (oid 19) when they should be
> char16 (oid 20)!  But char16eq is correctly defined to take char16
> in pg_operator.h.
>
> I'll work on this some more tonite.

Great.

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)