Horton

Re: Rethinking plpgsql's assignment implementation

Pavel Stehule <pavel.stehule@gmail.com>

View thread View on postgr.es
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Chapman Flack <chap@anastigmatix.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-12-26T18:00:16Z
Lists: pgsql-hackers

Attachments

Hi

I repeated tests. I wrote a set of simple functions. It is a synthetical
test, but I think it can identify potential problems well.

I calculated the average of 3 cycles and I checked the performance of each
function. I didn't find any problem. The total execution time is well too.
Patched code is about 11% faster than master (14sec x 15.8sec). So there is
new important functionality with nice performance benefits.

make check-world passed

Regards

Pavel

Commits

  1. Rethink the "read/write parameter" mechanism in pl/pgsql.

  2. Remove PLPGSQL_DTYPE_ARRAYELEM datum type within pl/pgsql.

  3. Re-implement pl/pgsql's expression and assignment parsing.

  4. Add the ability for the core grammar to have more than one parse target.

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

  6. Improve handling of array elements as getdiag_targets and cursor_variables.