On Tue, Apr 12, 2022 at 8:55 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tue, Apr 12, 2022 at 8:49 AM Tom Lane wrote:
>
>> "David G. Johnston" writes:
>> > - A function that's marked as dependent on an extension is
>> automatically
>> > - dropped when the extension i
On Tue, Apr 12, 2022 at 8:49 AM Tom Lane wrote:
> "David G. Johnston" writes:
> > - A function that's marked as dependent on an extension is
> automatically
> > - dropped when the extension is dropped.
> > + A function that's marked as dependent on an extension is skipped
> during
"David G. Johnston" writes:
> - A function that's marked as dependent on an extension is automatically
> - dropped when the extension is dropped.
> + A function that's marked as dependent on an extension is skipped during
> + dependency checking in restrict mode linkend="sql-d
On Thu, Feb 17, 2022 at 9:32 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Thu, Feb 17, 2022 at 8:54 PM Tom Lane wrote:
>
>> "David G. Johnston" writes:
>> > On Thu, Feb 17, 2022 at 6:17 PM Tom Lane wrote:
>> >> There is no bug here; it's operating as designed and documented.
>
On Fri, Feb 18, 2022 at 6:16 PM Bryn Llewellyn wrote:
>
> (4) The clue to the whole thing is the semantics of the LoV for
> "pg_depend. deptype" (see below) — but you all kept this a secret from me!
>
I didn't even think to look at the system catalogs for guidance in this
kind of thing. The cat
> david.g.johns...@gmail.com wrote:
>
> It's not a member though; there's a different syntax for that (ALTER
> EXTENSION name ADD member_object). The differences are a bit subtle, but for
> example making the function an extension member would change how pg_dump
> treats it.
I read, and re-re
On Thu, Feb 17, 2022 at 8:54 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > On Thu, Feb 17, 2022 at 6:17 PM Tom Lane wrote:
> >> There is no bug here; it's operating as designed and documented.
> >> Maybe the docs need some refinement.
>
> > We should just say that ALTER FUNCTION ALTER DE
"David G. Johnston" writes:
> On Thu, Feb 17, 2022 at 6:17 PM Tom Lane wrote:
>> There is no bug here; it's operating as designed and documented.
>> Maybe the docs need some refinement.
> We should just say that ALTER FUNCTION ALTER DEPENDS ON makes the target
> function/procedure a (transient?)
On Thu, Feb 17, 2022 at 7:30 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Thu, Feb 17, 2022 at 6:17 PM Tom Lane wrote:
>
>> "David G. Johnston" writes:
>> > Maybe, but the behavior does exist but is bugged in its current state.
>> > Whether it is advisable for users to use this
On Thu, Feb 17, 2022 at 6:17 PM Tom Lane wrote:
> "David G. Johnston" writes:
> > Maybe, but the behavior does exist but is bugged in its current state.
> > Whether it is advisable for users to use this feature is immaterial, the
> > bug needs to be fixed so that is works as documented for those
"David G. Johnston" writes:
> Maybe, but the behavior does exist but is bugged in its current state.
> Whether it is advisable for users to use this feature is immaterial, the
> bug needs to be fixed so that is works as documented for those that choose
> to do so.
There is no bug here; it's opera
the trigger function to the extension were
installed then the attempt to drop the extension would either fail
(restrict) or the trigger function you created would be deleted (cascade).
You would not be left with a trigger function referencing an extension
function that no longer exists.
> This simply is
rk. The trigger depends statically on its
function, and this is recorded in metadata. This is feasible because the
"create trigger" SQL expresses this in a way that is fully understood at
"create" time. In contrast, the trigger function depends only dynamically
(maybe "emergen
On Thu, Feb 17, 2022 at 11:15 AM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> and the documentation for ALTER FUNCTION should read "...as dependent on
> an extension may be dropped when the extension is dropped".
>
Nevermind this - if the extension is dropped the function will go awa
On Thu, Feb 17, 2022 at 10:04 AM Adrian Klaver
wrote:
> On 2/17/22 08:52, Bryn Llewellyn wrote:
> > **Briefly**
> >
>
> > *qu. 2.* Why does "drop extension restrict" quietly succeed—having the
> > effect of cascade-dropping any subprogram that you've altered to depend
> > on the extension in ques
On 2022-Feb-17, Bryn Llewellyn wrote:
> qu. 1. What is the use-case for "alter function/procedure depends on
> extension"?
Suppose you have an extension that implements change auditing for
tables, which works by creating triggers on the audited tables. You
enable auditing for
On 2/17/22 08:52, Bryn Llewellyn wrote:
**Briefly**
*qu. 2.* Why does "drop extension restrict" quietly succeed—having the
effect of cascade-dropping any subprogram that you've altered to depend
on the extension in question? This is at odds with the documented
meaning of "restrict".
But n
*Briefly*
qu. 1. What is the use-case for "alter function/procedure depends on extension"?
After all, subprograms depend, functionally, on all sorts of things. But
(unlike in Oracle Database) there’s (almost) no semantic check at “create” time
and therefore nothing like the sema
18 matches
Mail list logo
