On Mon, Jul 10, 2023 at 11:04:48AM -0400, Tom Lane wrote:
> ISTR that we discussed forbidding such changes way back when the
> extension mechanism was invented, and decided against it on the
> grounds that (a) it'd be nanny-ism, (b) we'd have to add checks in an
> awful lot of places and it'd be ea
Alvaro Herrera writes:
> On 2023-Jul-10, Tom Lane wrote:
>> The user has altered properties of an extension member
>> object locally within the database, but has not changed the extension's
>> installation script to match.
> If I were developing an extension and decided, down the line, to have
>
On 2023-Jul-10, Tom Lane wrote:
> Michael Paquier writes:
> > On Thu, Jul 06, 2023 at 10:09:20AM -0700, Andres Freund wrote:
> >> I also don't think pg_dump will dump the changed schema, which means a
> >> dump/restore leads to a different schema - IMO something to avoid.
>
> > Yes, you're right
Michael Paquier writes:
> On Thu, Jul 06, 2023 at 10:09:20AM -0700, Andres Freund wrote:
>> I also don't think pg_dump will dump the changed schema, which means a
>> dump/restore leads to a different schema - IMO something to avoid.
> Yes, you're right here. The function dumped is restored in th
On Fri, Jul 07, 2023 at 06:12:48PM +, Akshat Jaimini wrote:
> I believe it is ready to be committed!
Okay, thanks. Please note that I have backpatched the bug and added
the checks for the callers of changeDependencyFor() on HEAD on top of
the bugfix.
--
Michael
signature.asc
Description: PG
On Thu, Jul 06, 2023 at 10:09:20AM -0700, Andres Freund wrote:
> Well, it adds an exploitation opportunity. If other functions in the extension
> reference the original location (explicitly or via search_path), somebody else
> can create a function there, which might be called from a more privilege
On Thu, Jul 06, 2023 at 06:41:49PM +0200, Peter Eisentraut wrote:
> On 29.06.23 01:36, Michael Paquier wrote:
>> While working on a different patch, I have noted three code paths that
>> call changeDependencyFor() but don't check that they do not return
>> errors. In all the three cases (support f
The patch looks fine and passes all the tests. I am using Arch Linux on an
x86_64 system.
The patch does not cause any unnecessary bugs and does not make any non trivial
changes to the source code.
I believe it is ready to be committed!
The new status of this patch is: Ready for Committer
Hi,
On 2023-07-05 14:10:42 +0900, Michael Paquier wrote:
> On Tue, Jul 04, 2023 at 02:40:04PM -0400, Tom Lane wrote:
> > Alvaro Herrera writes:
> >> Hmm, shouldn't we disallow moving the function to another schema, if the
> >> function's schema was originally determined at extension creation time
On 29.06.23 01:36, Michael Paquier wrote:
While working on a different patch, I have noted three code paths that
call changeDependencyFor() but don't check that they do not return
errors. In all the three cases (support function, extension/schema
and object/schema), it seems to me that only one
On Thu, Jun 29, 2023 at 10:06:35AM +0300, Heikki Linnakangas wrote:
> The error messages like "failed to change schema dependency for extension"
> don't conform to the usual error message style. "could not change schema
> dependency for extension" would be more conformant. I see that you
> copy-pas
On Tue, Jul 04, 2023 at 02:40:04PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
>> Hmm, shouldn't we disallow moving the function to another schema, if the
>> function's schema was originally determined at extension creation time?
>> I'm not sure we really want to allow moving objects of an ext
Alvaro Herrera writes:
> Hmm, shouldn't we disallow moving the function to another schema, if the
> function's schema was originally determined at extension creation time?
> I'm not sure we really want to allow moving objects of an extension to a
> different schema.
Why not? I do not believe tha
On 2023-Jun-29, Heikki Linnakangas wrote:
> I can hit the above error with the attached test case. That seems wrong,
> although I don't know if it means that the check is wrong or it exposed a
> long-standing bug.
> +CREATE SCHEMA test_func_dep1;
> +CREATE SCHEMA test_func_dep2;
> +CREATE EXTENSI
On 29/06/2023 02:36, Michael Paquier wrote:
Hi all,
While working on a different patch, I have noted three code paths that
call changeDependencyFor() but don't check that they do not return
errors. In all the three cases (support function, extension/schema
and object/schema), it seems to me tha
15 matches
Mail list logo
