Re: [PATCH] Generic type subscription

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
Cc: Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru>, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Victor Wagner <vitus(at)wagner(dot)pp(dot)ru>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
Subject: Re: [PATCH] Generic type subscription
Date: 2017-01-23 19:36:00
Message-ID: 19890.1485200160@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-01-23 19:44:53 Re: Undefined psql variables
Previous Message David Christensen 2017-01-23 19:11:20 Re: Online enabling of page level checksums