public inbox for [email protected]  
help / color / mirror / Atom feed
From: Regina Obe <[email protected]>
To: [email protected]
Cc: 'Tom Lane' <[email protected]>
Cc: 'Gregory Stark (as CFM)' <[email protected]>
Cc: [email protected]
Cc: 'Regina Obe' <[email protected]>
Subject: RE: Ability to reference other extensions by schema in extension scripts
Date: Mon, 13 Mar 2023 10:28:04 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <20230313115916.ivvg4tj54szeu5rj@c19>
References: <[email protected]>
	<167762779361.628976.14009177203307564086.pgcf@coridan.postgresql.org>
	<CAM-w4HP91M-r=h4nExwonHf03SRwKyNYnvFHX2FFoFMv0pRQBA@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<20230313115916.ivvg4tj54szeu5rj@c19>

> I've given a try to this patch. It builds and regresses fine.
> 
> My own tests also worked fine. As long as ext1 was found in the ext2's
> no_relocate list it could not be relocated, and proper error message is
given
> to user trying it.
> 
> Nitpicking, there are a few things that are weird to me:
> 
> 1) I don't get any error/warning if I put an arbitrary string into
no_relocate
> (there's no check to verify the no_relocate is a subset of the requires).
> 

I thought about that and decided it wasn't worth checking for.  If an
extension author puts in an extension not in requires it's on them as the
docs say it should be in requires.

It will just pretend that extension is not listed in no_relocate.

> 2) An extension can still reference extensions it depends on without
putting
> them in no_relocate. This may be intentional, as some substitutions may
not
> require blocking relocation, but felt inconsistent with the normal
> @extschema@ which is never replaced unless an extension is marked as non-
> relocatable.
> 
> --strk;
> 
>   Libre GIS consultant/developer
>   https://strk.kbt.io/services.html


Yes this is intentional.  As Tom mentioned, if for example an extension
author decides
To schema qualify @extschema:foo@ in their table definition, and they marked
as requiring foo
since such a reference 
is captured by a schema move, there is no need for them to prevent relocate
of the foo extension (assuming foo was relocatable to begin with)







view thread (14+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: RE: Ability to reference other extensions by schema in extension scripts
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox