Re: [HACKERS] [PATCH] Generic type subscription

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] [PATCH] Generic type subscription
Дата
Msg-id 19890.1485200160@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] Generic type subscription  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] [PATCH] Generic type subscription  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
I wrote:
> ... (If that means
> we use two functions not one per datatype, that's fine with me.)

Actually, after thinking about that a bit more: you've really squeezed
*three* different APIs into one function.  Namely, subscript-reference
parse analysis, array subscripting execution, and array assignment
execution.  It would be cleaner, and would reduce runtime overhead a bit,
if those were embodied as three separate functions.

It might be possible to get away with having only one pg_type column,
pointing at the parse-analysis function.  That function would generate
a SubscriptingRef tree node containing the OID of the appropriate
execution function, which execQual.c could call without ever knowing
its name explicitly.

This clearly would work for built-in types, since the parse-analysis
function could rely on fmgroids.h for the OIDs of the execution functions.
But I'm less sure if it would work in extensions, which won't have
predetermined OIDs for their functions.  Is there a way for a function
in an extension to find the OID of one of its sibling functions?
        regards, tom lane



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

Предыдущее
От: David Christensen
Дата:
Сообщение: Re: [HACKERS] Online enabling of page level checksums
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Undefined psql variables