Pavel Stehule <pavel.steh...@gmail.com> writes: > this patch significantly reduce a ccache searching.
I looked at this patch a little bit. It's got a very serious problem: it supposes that the parent of an ARRAYELEM datum must be a VAR datum, which is not so. As an example, it gets an Assert failure on this: create table rtype (id int, ar text[]); create or replace function foo() returns text[] language plpgsql as $$ declare r record; begin r := row(12, '{foo,bar,baz}')::rtype; r.ar[2] := 'replace'; return r.ar; end$$; select foo(); There is not any good place to keep the array element lookup data for the non-VAR cases that is comparable to what you did for VAR. I wasn't exactly thrilled about adding another field to PLpgSQL_var anyway, because it would go unused in the large majority of cases. A possible solution is to use the ARRAYELEM datum itself to hold the cached lookup data. I'm not sure if it's worth having a level of indirection as you do here; you might as well just drop the fields right into PLpgSQL_arrayelem, because they'd be used in the vast majority of cases. Also, in order to deal with subscripting record fields, you'd better be prepared for the possibility that the target array type changes from time to time. I'd envision this working similarly to what various array-manipulating functions do: you remember the last input OID you looked up, and whenever that changes, repeat the lookup steps. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers