Horton

Re: [PATCH] Generic type subscription

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Dmitry Dolgov <9erthalion6@gmail.com>
Cc: Artur Zakirov <a.zakirov@postgrespro.ru>, Aleksander Alekseev <a.alekseev@postgrespro.ru>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Victor Wagner <vitus@wagner.pp.ru>, Haribabu Kommi <kommi.haribabu@gmail.com>
Date: 2017-01-23T19:36:00Z
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

Commits

  1. Throw error when assigning jsonb scalar instead of a composite object

  2. Filling array gaps during jsonb subscripting

  3. Implementation of subscripting for jsonb

  4. Support subscripting of arbitrary types, not only arrays.

  5. Remove obsoleted code relating to targetlist SRF evaluation.

  6. Include <sys/select.h> where needed