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

Поиск
Список
Период
Сортировка
От darrenk@insightdist.com (Darren King)
Тема Re: AW: [HACKERS] varchar() vs char16 performance
Дата
Msg-id 9803191729.AA79216@ceodev
обсуждение исходный текст
Ответ на AW: [HACKERS] varchar() vs char16 performance  (Zeugswetter Andreas <andreas.zeugswetter@telecom.at>)
Ответы Re: AW: [HACKERS] varchar() vs char16 performance  (Bruce Momjian <maillist@candle.pha.pa.us>)
Список pgsql-hackers
> 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.

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.

darrenk

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Zeugswetter Andreas
Дата:
Сообщение: Re: [HACKERS] varchar() vs char16 performance
Следующее
От: "Kent S. Gordon"
Дата:
Сообщение: Re: [HACKERS] standards question