From: | Jiří Fejfar <jurafejfar(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: extensions are hitting the ceiling |
Date: | 2019-03-19 10:47:13 |
Message-ID: | CA+8wVNUOt2Bh4x7YQEVoq5BfP=jM-F6cDYKxJiTODG_VCGhUVQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi all!
We are also facing some issues when using extensions. We are using
them quite intensively as a tool for maintaining our custom "DB
applications" with versioning, all tables, data, regression tests...
We find extensions great! We do not need other tool like flyway. My
colleague already posted some report to bug mailing list [1] but with
no response.
Our observations correspond well with your outline:
#1: Dependencies
* It is not possible to specify the version of extension we are
dependent on in .control file.
#2: Data in Extensions
I am not sure about the name "Configuration" Tables. From my point of
view extensions can hold two sorts of data:
1) "static" data: delivered with extension, inserted by update
scripts; the same "static" data are present across multiple
installation of extension in the same version. This data are not
supposed to be dumped.
2) "dynamic" data: inserted by users, have to be included in dumps,
are marked with pg_extension_config_dump and are called
"configuration" tables/data ... but why "configuration"?
#3 pg_dump and Extensions
* We have described some behavior of pg_dump, which we believe are in
fact bugs: see [1] "1) pg_dump with --schema parameter" and "2)
Hanging OID in extconfig".
* Maybe it would be good to introduce new switch pg_dump --extension
extA dumping all "dynamic" data from extension tables regardless on
schema
#4: Extension owned
* It is not possible to alter extension owner
Thanks, Jiří & Ivo.
[1] https://www.postgresql.org/message-id/15616-260dc9cb3bec7e7e@postgresql.org
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2019-03-19 10:48:25 | Re: Offline enabling/disabling of data checksums |
Previous Message | Kyotaro HORIGUCHI | 2019-03-19 10:47:05 | Re: Willing to fix a PQexec() in libpq module |