From: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: creating extension including dependencies |
Date: | 2015-07-24 15:59:13 |
Message-ID: | 55B260D1.3000404@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015-07-22 07:12, Michael Paquier wrote:
> On Tue, Jul 21, 2015 at 11:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Petr Jelinek <petr(at)2ndquadrant(dot)com> writes:
>>> ... My main question is if we are
>>> ok with SCHEMA having different behavior with CASCADE vs without
>>> CASCADE. I went originally with "no" and added the DEFAULT flag to
>>> SCHEMA. If the answer is "yes" then we don't need the flag (in that case
>>> CASCADE acts as the flag).
>>
>> Yeah, I was coming around to that position as well. Insisting that
>> SCHEMA throw an error if the extension isn't relocatable makes sense
>> as long as only one extension is being considered, but once you say
>> CASCADE it seems like mostly a usability fail. I think it's probably
>> OK if with CASCADE, SCHEMA is just "use if needed else ignore".
>
Here is a patch implementing that. Note that the checks are now done in
different order for non-relocatable extension when SCHEMA is specified
than previously. Before the patch, the SCHEMA was first checked for
conflict with the extension's schema and then there was check for schema
existence. This patch always checks for schema existence first, mainly
to keep code saner (to my eyes).
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachment | Content-Type | Size |
---|---|---|
create-extension-cascade-2015-07-24.patch | text/x-diff | 25.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2015-07-24 16:55:46 | Re: BRIN index and aborted transaction |
Previous Message | Pavan Deolasee | 2015-07-24 15:15:13 | Re: POC: Cache data in GetSnapshotData() |