| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
| Cc: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL-Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Extensions support for pg_dump, patch v27 |
| Date: | 2011-01-26 17:17:00 |
| Message-ID: | 19929.1296062220@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
>>> The missing entry in pg_depend is the reason why the extension is not
>>> part of the dump. We could fix that using a LEFT JOIN here and COALESCE
>>> to force the namespace as pg_catalog. Is that not a kludge?
>> Yes, it is. Why is the pg_depend entry missing?
> See src/backend/catalog/pg_depend.c
> Certainly, pg_catalog is pinned.
OK, so I guess I'm missing why the extension code is looking for stuff
dependent on the pg_catalog schema. That schema certainly doesn't
belong to any extension.
In any case, your proposed hack above is effectively assuming that
there's only one pinned schema, which is untrue now and is likely to
become even less true in the future. So I don't think we can go that way.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2011-01-26 17:22:43 | Re: SSI, simplified |
| Previous Message | Kevin Grittner | 2011-01-26 17:07:18 | Re: SSI patch version 14 |