On Fri, Aug 5, 2022 at 6:58 PM Alvaro Herrera wrote:
> OK, pushed. This soon caused buildfarm to show a failure due to
> underspecified ORDER BY, so I just pushed a fix for that too.
Thank you.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
OK, pushed. This soon caused buildfarm to show a failure due to
underspecified ORDER BY, so I just pushed a fix for that too.
Thanks Simon for reporting the problem, and thanks Amit for the patch.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
"Si quieres ser c
On Thu, Aug 4, 2022 at 9:56 PM Alvaro Herrera wrote:
> Another point for backpatch: EnableDisableTrigger() changes API, which
> is potentially not good. In backbranches I'll keep the function
> unchanged and add another function with the added argument,
> EnableDisableTriggerNew().
+1
> So exte
Another point for backpatch: EnableDisableTrigger() changes API, which
is potentially not good. In backbranches I'll keep the function
unchanged and add another function with the added argument,
EnableDisableTriggerNew().
So extensions that want to be compatible with both old and current
versions
On Thu, Aug 4, 2022 at 3:01 AM Alvaro Herrera wrote:
> On 2022-Aug-02, Amit Langote wrote:
> > Regarding the patch, I agree that storing the recurse flag rather than
> > overwriting subtype might be better.
> >
> > + boolexecTimeRecursion; /* set by ATPrepCmd if ATExecCmd must
> > +
On 2022-Aug-02, Amit Langote wrote:
> Regarding the patch, I agree that storing the recurse flag rather than
> overwriting subtype might be better.
>
> + boolexecTimeRecursion; /* set by ATPrepCmd if ATExecCmd must
> + * recurse to children */
>
> Migh
On Tue, Aug 2, 2022 at 3:58 AM Alvaro Herrera wrote:
> On 2022-Aug-01, Amit Langote wrote:
>
> > On Sat, Jul 30, 2022 at 5:25 AM Tom Lane wrote:
>
> > > I do not think it's a great idea to have ALTER TABLE scribbling on
> > > the source parsetree.
> >
> > Hmm, I think we already do scribble on th
Alvaro Herrera writes:
> No, actually nothing scribbles on the parsetree, because ATPrepCmd is
> working on a copy of the node, so there's no harm done to the original.
Oh, okay then. Maybe this needs to be noted somewhere?
regards, tom lane
On 2022-Aug-01, Amit Langote wrote:
> On Sat, Jul 30, 2022 at 5:25 AM Tom Lane wrote:
> > I do not think it's a great idea to have ALTER TABLE scribbling on
> > the source parsetree.
>
> Hmm, I think we already do scribble on the source parse tree even
> before this patch, for example, as ATPre
On Sat, Jul 30, 2022 at 5:25 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > Yeah, I don't know about adding tons of values to that enum just so that
> > we can use that to hide a boolean inside. Why not add a boolean to the
> > containing struct? Something like the attached.
>
> I do not think
Alvaro Herrera writes:
> Yeah, I don't know about adding tons of values to that enum just so that
> we can use that to hide a boolean inside. Why not add a boolean to the
> containing struct? Something like the attached.
I do not think it's a great idea to have ALTER TABLE scribbling on
the sou
On 2022-May-24, Amit Langote wrote:
> So, I think we should do something like the attached. A lot of
> boilerplate is needed given that the various enable/disable trigger
> variants are represented as separate sub-commands (AlterTableCmd
> subtypes), which can perhaps be avoided by inventing a
>
On Thu, Jul 14, 2022 at 8:20 PM Dmitry Koval wrote:
> > I agree that the patch shouldn't have changed that behavior, so I've
> > fixed the patch so that EnableDisableTrigger() recurses even if the
> > parent trigger is unchanged.
>
> Thanks, I think this patch is ready for committer.
Great, thank
I agree that the patch shouldn't have changed that behavior, so I've
fixed the patch so that EnableDisableTrigger() recurses even if the
parent trigger is unchanged.
Thanks, I think this patch is ready for committer.
--
With best regards,
Dmitry Koval
Postgres Professional: http://postgrespro.
Hi,
On Fri, Jul 8, 2022 at 3:44 AM Dmitry Koval wrote:
> I've looked through the code and everything looks good.
> But there is one thing I doubt.
> Patch changes result of test:
>
>
> create function trig_nothing() returns trigger language plpgsql
>as $$ begin return null; end $$;
> cre
Hi!
I've looked through the code and everything looks good.
But there is one thing I doubt.
Patch changes result of test:
create function trig_nothing() returns trigger language plpgsql
as $$ begin return null; end $$;
create table parent (a int) partition by list (a);
create table child1
On Tue, May 24, 2022 at 3:11 PM Amit Langote wrote:
> Simon reported $subject off-list.
>
> For triggers on partitioned tables, various enable/disable trigger
> variants recurse to also process partitions' triggers by way of
> ATSimpleRecursion() done in the "prep" phase. While that way of
> recu
On Fri, May 27, 2022 at 5:11 PM Peter Eisentraut
wrote:
> On 24.05.22 23:23, Zhihong Yu wrote:
> > Hi,
> >
> > AT_EnableTrig, /* ENABLE TRIGGER name */
> > + AT_EnableTrigRecurse, /* internal to commands/tablecmds.c */
> > AT_EnableAlwaysTrig,/* ENABLE ALWAYS
On 24.05.22 23:23, Zhihong Yu wrote:
Hi,
AT_EnableTrig, /* ENABLE TRIGGER name */
+ AT_EnableTrigRecurse, /* internal to commands/tablecmds.c */
AT_EnableAlwaysTrig, /* ENABLE ALWAYS TRIGGER name */
+ AT_EnableAlwaysTrigRecurse, /* internal to commands/t
Hi,
AT_EnableTrig, /* ENABLE TRIGGER name */
+ AT_EnableTrigRecurse, /* internal to commands/tablecmds.c */
AT_EnableAlwaysTrig,/* ENABLE ALWAYS TRIGGER name */
+ AT_EnableAlwaysTrigRecurse, /* internal to commands/tablecmds.c */
Is it better to put the new
Hi,
Simon reported $subject off-list.
For triggers on partitioned tables, various enable/disable trigger
variants recurse to also process partitions' triggers by way of
ATSimpleRecursion() done in the "prep" phase. While that way of
recursing is fine for row-level triggers which are cloned to
pa
21 matches
Mail list logo