Обсуждение: Using test_ddl_deparse as an extension
I am interested in using the exact functionality in test_ddl_deparse which provides the sub command types for alter table statements. I would prefer to leverage this code which has already been vetted by the community, and also not just duplicate this code myself, or package it up myself.
It would be nice to just use the extension. But I'm interested to hear what recommendations could be given for my use case (for that matter - what is the recommendation to anyone wanting to use the exact functionality provided in a postgres test module).
My specific intention is for sending DDL via logical replication, and ignoring, for example, enable/disable trigger statements when I am using selective replication.
Many thanks!
Jeremy
On 2018-Jul-25, Jeremy Finzel wrote: > I am interested in using the exact functionality in test_ddl_deparse which > provides the sub command types for alter table statements. I would prefer > to leverage this code which has already been vetted by the community, and > also not just duplicate this code myself, or package it up myself. > > It would be nice to just use the extension. But I'm interested to hear > what recommendations could be given for my use case (for that matter - what > is the recommendation to anyone wanting to use the exact functionality > provided in a postgres test module). > > My specific intention is for sending DDL via logical replication, and > ignoring, for example, enable/disable trigger statements when I am using > selective replication. The design for the intended functionality was to emit a JSON blob that could be modified or examined programmatically; so you would be able to obtain specific bits of knowledge (is this going into schema XYZ? etc). There was a module that was about 90% complete before I abandoned it because of changing priorities, needed just "a little push" and I never got around to doing that. Alexander Shulgin spent some time with it and moved it forward a good bit, but I didn't get time to review his work, so he understandably gave up. I think with a little bit more effort we could get it in core, which I'd love ... That test code was more a placeholder to have *something* to ensure we didn't completely break the feature, but I don't really see it as a good way forward for the feature. Let's not turn it into a production-level feature. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services