Replies: 1 comment
|
Proposed a patch upstream: https://www.postgresql.org/message-id/CAG%3DVW17kAweKGwqtVU8vn71uRCOS9yxnyEnoa%3D-3sAuyZt5O6g%40mail.gmail.com |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Here's an interesting problem. Let's suppose we have two extensions, A and B.
A has a table
a_config. The rows are marked withbundledcolumn to make surepg_extension_config_dumpdoesn't capture data provided by the etension itself. All good so far.A defines a function
f()that effectively adds new records toa_configNow, extension B depends A, and uses
A.f()to add new records. However, they are not considered bundled anymore – unless we do something explicit about it.The problem is that now when pg_dump will attempt to restore data after getting A installed, it'll send duplicates to be inserted.
So far, the only solution I have is to introduce a setting that opting in extensions would have to set – something to the tune of
extension.create_in_progressandbundledshould look into it to determine if the record should be considered bundled.If this works well enough, perhaps this can be proposed upstream to make Postgres set such a variable when extensions are being installed. Another way to do this would be to expose
creating_extensionas a function https://doxygen.postgresql.org/extension_8c.html#a5f774b51db47b6cae5dbf63f6035cbcfThoughts?
All reactions