On 2018/04/30 18:38, Ashutosh Bapat wrote:
> On Fri, Mar 23, 2018 at 7:19 PM, Alvaro Herrera
> wrote:
>> Pushed. Thanks for all the review.
>>
>
> https://www.postgresql.org/docs/devel/static/ddl-partitioning.html
>
> section 5.10.2.3 still says
> "Row triggers, if necessary, must be defined o
On Fri, Mar 23, 2018 at 7:19 PM, Alvaro Herrera wrote:
> Pushed. Thanks for all the review.
>
https://www.postgresql.org/docs/devel/static/ddl-partitioning.html
section 5.10.2.3 still says
"Row triggers, if necessary, must be defined on individual partitions,
not the partitioned table."
Should
Pushed. Thanks for all the review.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut wrote:
> On 3/21/18 19:18, Alvaro Herrera wrote:
> > Here's v8, which addresses all your comments except the doc updates. I
> > added a few more tests, too. Thanks for the review! I intend to commit
> > this shortly, probably not before Friday to give some more time for
> > othe
On 3/21/18 19:18, Alvaro Herrera wrote:
> Here's v8, which addresses all your comments except the doc updates. I
> added a few more tests, too. Thanks for the review! I intend to commit
> this shortly, probably not before Friday to give some more time for
> others to review/comment.
Looks good,
Here's v8, which addresses all your comments except the doc updates. I
added a few more tests, too. Thanks for the review! I intend to commit
this shortly, probably not before Friday to give some more time for
others to review/comment.
Some notes:
Peter Eisentraut wrote:
> I'm not sure why yo
On 3/9/18 15:41, Alvaro Herrera wrote:
>> One thing I'd like to add before claiming this committable (backend-
>> side) is enabling constraint triggers. AFAICT that requires a bit of
>> additional logic, but it shouldn't be too terrible. This would allow
>> for deferrable unique constraints, for
On 3/9/18 16:05, Alvaro Herrera wrote:
> ... and this little addendum makes pg_dump work correctly.
The header file says "recursing", but the .c file calls the argument
"in_partition".
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
On Fri, Mar 9, 2018 at 7:06 AM, Alvaro Herrera wrote:
> Thomas Munro wrote:
>> +create trigger failed after update on parted_trig
>> + referencing old table as old_table
>> + for each statement execute procedure trigger_nothing();
>>
>> It doesn't fail as you apparently expected. Perhaps it was
Peter Eisentraut wrote:
> On 3/7/18 20:57, Alvaro Herrera wrote:
> > So, unless someone has a brilliant idea on how to construct a column
> > mapping from partitioned table to partition, I'm going back to the
> > design I was proposing earlier, ie., creating individual pg_trigger rows
> > for each
... and this little addendum makes pg_dump work correctly.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c
index 867bbe8f1e..ca0a66753e 100644
Alvaro Herrera wrote:
> One thing I'd like to add before claiming this committable (backend-
> side) is enabling constraint triggers. AFAICT that requires a bit of
> additional logic, but it shouldn't be too terrible. This would allow
> for deferrable unique constraints, for example.
v7 support
Peter Eisentraut wrote:
> On 3/7/18 20:57, Alvaro Herrera wrote:
> > So, unless someone has a brilliant idea on how to construct a column
> > mapping from partitioned table to partition, I'm going back to the
> > design I was proposing earlier, ie., creating individual pg_trigger rows
> > for each
On 3/7/18 20:57, Alvaro Herrera wrote:
> So, unless someone has a brilliant idea on how to construct a column
> mapping from partitioned table to partition, I'm going back to the
> design I was proposing earlier, ie., creating individual pg_trigger rows
> for each partition that are essentially adj
Thomas Munro wrote:
> What is this test for?
>
> +create trigger failed after update on parted_trig
> + referencing old table as old_table
> + for each statement execute procedure trigger_nothing();
>
> It doesn't fail as you apparently expected. Perhaps it was supposed
> to be "for each row"
Alvaro Herrera wrote:
> I reserve the right to revise this further, as I'm going to spend a
> couple of hours looking at it this afternoon, particularly to see how
> concurrent DDL behaves, but I don't see anything obviously wrong with
> it.
I do now. TLDR; I'm afraid this cute idea crashed and
On Thu, Mar 8, 2018 at 6:17 AM, Alvaro Herrera wrote:
> Here's another version of this patch. It is virtually identical to the
> previous one, except for a small doc update and whitespace changes.
What is this test for?
+create trigger failed after update on parted_trig
+ referencing old table
Here's another version of this patch. It is virtually identical to the
previous one, except for a small doc update and whitespace changes.
To recap: when a row-level trigger is created on a partitioned table, it
is marked tginherits; partitions all have their pg_class row modified
with relhastrig
On Thu, Feb 22, 2018 at 6:52 PM, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>> Another option is to rethink this feature from the ground up: instead of
>> cloning catalog rows for each children, maybe we should have the trigger
>> lookup code, when running DML on the child relation (the partiti
Amit Langote wrote:
> On Fri, Feb 23, 2018 at 11:32 AM, Alvaro Herrera
> wrote:
> > Uh, wow, how have I missed that all this time! Yes, it probably does.
> > I'll rework this tomorrow ... and the already committed index patch too,
> > I think.
>
> BTW, not sure if you'd noticed but I had emaile
On Fri, Feb 23, 2018 at 11:32 AM, Alvaro Herrera
wrote:
> Amit Langote wrote:
>> On 2018/02/23 8:52, Alvaro Herrera wrote:
>> > We could mitigate the performance loss to some extent by adding more to
>> > RelationData. For example, a "is_partition" boolean would help: skip
>> > searching pg_inher
Amit Langote wrote:
> On 2018/02/23 8:52, Alvaro Herrera wrote:
> > We could mitigate the performance loss to some extent by adding more to
> > RelationData. For example, a "is_partition" boolean would help: skip
> > searching pg_inherits for a relation that is not a partition.
>
> Unless I'm miss
On 2018/02/23 8:52, Alvaro Herrera wrote:
> We could mitigate the performance loss to some extent by adding more to
> RelationData. For example, a "is_partition" boolean would help: skip
> searching pg_inherits for a relation that is not a partition.
Unless I'm missing something, doesn't rd_rel->r
Alvaro Herrera wrote:
> Another option is to rethink this feature from the ground up: instead of
> cloning catalog rows for each children, maybe we should have the trigger
> lookup code, when running DML on the child relation (the partition),
> obtain trigger entries not only for the child relatio
On 2/15/18 16:55, Alvaro Herrera wrote:
> Amit Langote wrote:
>> Do you mean to fire these triggers only if the parent table (not a child
>> table/partition) is addressed in the DML, right? If the table directly
>> addressed in the DML is a partition whose parent has a row-level trigger,
>> then t
On 2018/02/16 6:55, Alvaro Herrera wrote:
> Amit Langote wrote:
>> On 2018/02/15 6:26, Alvaro Herrera wrote:
>>> Another option is to rethink this feature from the ground up: instead of
>>> cloning catalog rows for each children, maybe we should have the trigger
>>> lookup code, when running DML on
Amit Langote wrote:
> On 2018/02/15 6:26, Alvaro Herrera wrote:
> > Another option is to rethink this feature from the ground up: instead of
> > cloning catalog rows for each children, maybe we should have the trigger
> > lookup code, when running DML on the child relation (the partition),
> > obta
On 2018/02/15 6:26, Alvaro Herrera wrote:
> Another option is to rethink this feature from the ground up: instead of
> cloning catalog rows for each children, maybe we should have the trigger
> lookup code, when running DML on the child relation (the partition),
> obtain trigger entries not only fo
Robert Haas wrote:
> On Tue, Jan 23, 2018 at 5:10 PM, Alvaro Herrera
> wrote:
> >> Also, does ALTER TABLE ... ENABLE/DISABLE TRIGGER do the right things on
> >> partitioned tables?
> >
> > Haven't done this yet, either. I like Simon's suggestion of outright
> > disallowing this.
>
> Why not ju
Moved to next commit fest.
There is some work to be done, but there appears to be a straight path
to success.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 2018/01/31 9:44, Peter Eisentraut wrote:
> On 1/30/18 04:49, Amit Langote wrote:
>>> If you are writing a generic
>>> trigger function, maybe to dump out all columns, you want to know the
>>> physical table and its actual columns. It's easy[citation needed] to
>>> get the partition root for a g
On 1/30/18 04:49, Amit Langote wrote:
>> If you are writing a generic
>> trigger function, maybe to dump out all columns, you want to know the
>> physical table and its actual columns. It's easy[citation needed] to
>> get the partition root for a given table, if the trigger code needs
>> that. Th
On 2018/01/30 5:30, Peter Eisentraut wrote:
> On 1/23/18 17:10, Alvaro Herrera wrote:
>> The main question is this: when running the trigger function, it is
>> going to look as it is running in the context of the partition, not in
>> the context of the parent partitioned table (TG_RELNAME etc). Th
On 1/23/18 17:10, Alvaro Herrera wrote:
> The main question is this: when running the trigger function, it is
> going to look as it is running in the context of the partition, not in
> the context of the parent partitioned table (TG_RELNAME etc). That
> seems mildly ugly: some users may be expecti
On Tue, Jan 23, 2018 at 5:10 PM, Alvaro Herrera wrote:
> The main question is this: when running the trigger function, it is
> going to look as it is running in the context of the partition, not in
> the context of the parent partitioned table (TG_RELNAME etc). That
> seems mildly ugly: some user
Peter Eisentraut wrote:
> On 12/29/17 17:53, Alvaro Herrera wrote:
> > This patch enables FOR EACH ROW triggers on partitioned tables.
> >
> > As presented, this patch is sufficient to discuss the semantics that we
> > want for triggers on partitioned tables, which is the most pressing
> > questio
On 3 January 2018 at 03:12, Peter Eisentraut
wrote:
> On 12/29/17 17:53, Alvaro Herrera wrote:
>> This patch enables FOR EACH ROW triggers on partitioned tables.
>>
>> As presented, this patch is sufficient to discuss the semantics that we
>> want for triggers on partitioned tables, which is the m
On 12/29/17 17:53, Alvaro Herrera wrote:
> This patch enables FOR EACH ROW triggers on partitioned tables.
>
> As presented, this patch is sufficient to discuss the semantics that we
> want for triggers on partitioned tables, which is the most pressing
> question here ISTM.
This seems pretty stra
38 matches
Mail list logo
