Re: Extensions, this time with a patch

Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> writes:
> * There are some compiler warnings. You might be missing something in
> copyfuncs and equalfuncs.

Fixed in v4, attached.

> * There might be some bugs in pg_dump:
> pg_dump: schema with OID 2200 does not exist, but is needed for object
> 16411

Fixed in v4, attached.

The problem was with the query used in pg_dump to filter out relations
that are part of an extension, in getTables(). A composite type will
create an underlying relation of relkind 'c', but there was no direct
dependency to the extension, thus the filter failed to bypass it.

It's fixed by adding a direct internal dependency between the relation
and the extension, as that's so much easier than doing a recursive scan
of pg_depend in pg_dump SQL queries.

I will try to find out if other cases are forgotten like this one.

Note that as a result you need to drop extension dblink then create it
again so that you benefit from the fix. Also note that drop extension is
recursively following the dependencies so is not concerned by this bug.

> * The example in the doc "CREATE EXTENSION hstore" dumps surprising
> warning messages,
> We would be better to avoid such messages, though it's not an issue
> for EXTENSION.
> ----
> WARNING: => is deprecated as an operator name
> DETAIL: This name may be disallowed altogether in future versions of
> PostgreSQL.
> CONTEXT: SQL statement "/* contrib/hstore/hstore.sql.in */
> (followed by dumped script)
> ----

I didn't realise that using SPI would mean dumping the all script in
case of even NOTICEs. May be we want to protect against that in the
CREATE EXTENSION case, but I didn't have a look at how to do it. Do we
want CREATE EXTENSION to be more quiet than SPI usually is?

> * Docs sql-createextension.html has two odd links:
> ----
> See Also
> DROP EXTENSION, Table 9-61, Appendix F
> ----

Fixed in v4, attached.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support