ry much,
Regards, Adger
--
发件人：Alvaro Herrera
发送时间：2021年1月18日(星期一) 20:36
收件人：Ashutosh Bapat
抄 送：Ashutosh Bapat ; Pg Hackers
主 题：Re: BEFORE ROW triggers for partitioned tables
Thanks for the reviews; I have pushed it now.
(I made the do
发件人：Alvaro Herrera
发送时间：2021年1月18日(星期一) 20:36
收件人：Ashutosh Bapat
抄 送：Ashutosh Bapat ; Pg Hackers
主 题：Re: BEFORE ROW triggers for partitioned tables
Thanks for the reviews; I have pushed it now.
(I made the doc edits you mentioned too.)
--
Álvaro Herrerahttps://www.2n
Thanks for the reviews; I have pushed it now.
(I made the doc edits you mentioned too.)
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2020-Mar-17, Ashutosh Bapat wrote:
> On Fri, 13 Mar 2020 at 21:55, Alvaro Herrera
> wrote:
> > Note that in this implementation I no longer know which column is the
> > problematic one, but I suppose users have clue enough. Wording
> > suggestions welcome.
>
> When we have expression as a p
I was expecting that documentation somewhere covered the fact that BR
triggers are not supported on a partitioned table. And this patch
would remove/improve that portion of the code. But I don't see any
documentation changes in this patch.
On Tue, Mar 17, 2020 at 10:11 PM Ashutosh Bapat
wrote:
>
On Fri, 13 Mar 2020 at 21:55, Alvaro Herrera
wrote:
> On 2020-Mar-11, Ashutosh Bapat wrote:
>
> > On Thu, Feb 27, 2020 at 10:22 PM Alvaro Herrera
> > wrote:
>
> > > * The new function I added, ReportTriggerPartkeyChange(), contains one
> > > serious bug (namely: it doesn't map attribute numbers
On 2020-Mar-11, Ashutosh Bapat wrote:
> On Thu, Feb 27, 2020 at 10:22 PM Alvaro Herrera
> wrote:
> > * The new function I added, ReportTriggerPartkeyChange(), contains one
> > serious bug (namely: it doesn't map attribute numbers properly if
> > partitions are differently defined).
>
> IIUC the
On 2020-03-12 05:17, Ashutosh Bapat wrote:
On Wed, Mar 11, 2020 at 8:53 PM Ashutosh Bapat
wrote:
Will it be easier to subject the new tuple to the partition level
constraints themselves and report if those are violated. See
RelationGetPartitionQual() for getting partition constraints. This
func
On Wed, Mar 11, 2020 at 8:53 PM Ashutosh Bapat
wrote:
>
> On Thu, Feb 27, 2020 at 10:22 PM Alvaro Herrera
> wrote:
> >
> > * The "root" is not necessarily the root partitioned table, but instead
> > it's the table that was named in the command. Because of this, we don't
> > need to acquire locks
On Thu, Feb 27, 2020 at 10:22 PM Alvaro Herrera
wrote:
>
> * The "root" is not necessarily the root partitioned table, but instead
> it's the table that was named in the command. Because of this, we don't
> need to acquire locks on the tables, since the executor already has the
> tables open and
On 2020-02-27 17:51, Alvaro Herrera wrote:
Enabling BEFORE triggers FOR EACH ROW in partitioned tables is very easy
-- just remove the check against them. With that, they work fine.
This looks good to me in principle. It's a useful thing to support.
1. Just let it be. If the user does some
Enabling BEFORE triggers FOR EACH ROW in partitioned tables is very easy
-- just remove the check against them. With that, they work fine.
The main problem is that the executor is not prepared to re-route the
tuple if the user decides to change the partitioning columns (so you get
the error that
12 matches
Mail list logo
