Kevin Grittner <kgri...@ymail.com> wrote: > I think this is approaching a committable state, although I think > it should probably be broken down to four separate patches.
And here they are. This should net to the same set of changes as the prior post, but the changes are logically separated. They are labeled as v3 to match the last post. trigger-transition-tables allows transition table names to be specified in a REFERENCING clause of CREATE TRIGGER, per spec, and creates tuplestores when needed in the TriggerData structure. It doesn't worry about who does what with that data. This doesn't depend on anything else. 15 files changed, 577 insertions(+), 43 deletions(-) spi-tuplestore-registry allows tuplestores, with associated name and TupleDesc, to be registered with the current SPI connection. Queries planned or executed on that connection will recognize the name as a tuplestore relation. It doesn't care who is registering the tuplestores or what happens to them. It doesn't depend on anything else. 5 files changed, 445 insertions(+) executor-tuplestore-relations covers parse analysis, planner/optimizer, and executor layers. It pulls information from the registry in a couple places, but is not very intertwined with SPI. That is the only registry it knows right now, but it should be easy to add other registries if needed. It doesn't care where the tuplestore came from, so we should be able to use this for other things. I have it in mind to use it for incremental maintenance of materialized views, but I expect that other uses will be found. It has a logical dependency on the spi-tuplestore-registry patch. While it doesn't have a logical dependency on trigger-transition-tables, they both modified some of the same files, and this won't apply cleanly unless trigger-transition-tables is applied first. If you hand-correct the failed hunks, it compiles and runs fine without trigger-transition-tables. 30 files changed, 786 insertions(+), 9 deletions(-) plpgsql-after-trigger-transition-tables takes the tuplestores from TriggerData and registers them with SPI before trigger planning and execution. It depends on the trigger-transition-tables and spi-tuplestore-registry patches to build, and won't do anything useful at run time without the executor-tuplestore-relations patch. 3 files changed, 37 insertions(+), 11 deletions(-) Hopefully this will make review easier. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
trigger-transition-tables-v3.patch.gz
Description: application/tgz
spi-tuplestore-registry-v3.patch.gz
Description: application/tgz
executor-tuplestore-relations-v3.patch.gz
Description: application/tgz
plpgsql-after-trigger-transition-tables-v3.patch.gz
Description: application/tgz
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
