On Tue, Dec 24, 2024 at 08:23:57AM -0600, Merlin Moncure wrote:
> Actually, I hadn't gotten that far yet; I was just noticing that:
> CALL foo(1,2,3);
> CALL foo(2,3,4);
> ...resolved to different queryids and if that was expected, and if not, if
> some logic tune-ups in the extension improve behav
On Mon, Dec 23, 2024 at 11:01 PM Michael Paquier
wrote:
> On Mon, Dec 23, 2024 at 10:06:58PM -0600, Merlin Moncure wrote:
> > I'm aware of that and will set it -- it's the only option if I'm
> following
> > you. The way I've been doing things lately for bulk processing is a lot
> > of orchestra
On Mon, Dec 23, 2024 at 10:06:58PM -0600, Merlin Moncure wrote:
> I'm aware of that and will set it -- it's the only option if I'm following
> you. The way I've been doing things lately for bulk processing is a lot
> of orchestrated procedures that are organized for purposes of monitoring
> and e
On Mon, Dec 23, 2024 at 3:58 PM Tom Lane wrote:
> Merlin Moncure writes:
> > Can this simply be disabled for stored procedures as a special case? I'm
> > hoping this might do something useful that is also safe. Curious if
> anyone
> > has any thoughts on this.
>
> No, I don't think that would
Merlin Moncure writes:
> Can this simply be disabled for stored procedures as a special case? I'm
> hoping this might do something useful that is also safe. Curious if anyone
> has any thoughts on this.
No, I don't think that would help. The restriction on utility
statements would cover CREATE
