I forgot to mention that while it is possible to auto-create partitions now, it is not ideal.
For example, now I'm back to using inheritance partitioned table, with ON BEFORE FOR EACH ROW trigger. That trigger creates new table, but it have to make an insert there by himself - because it can't reroute original query to another table; and then it have to RETURN NULL so insert is reported as if it didn't happen at all. So I can't use RETURNING auto_generated_id, for example.
>> The problem here is with the server allowing to create a partition of the >> table being inserted into, inside the table's BEFORE INSERT trigger.
That may be off-topic here, but I feel that *some* way of auto-creating partitions would be useful though.
Maybe all partitioning setup could boil down to one table declaration, with auto-created partitions of the same structure, including indices and stuff.
On 2018/10/19 11:52, Tom Lane wrote: > Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes: >> On 2018/10/18 20:57, PG Bug reporting form wrote: >>> I tried to use declarative partitioning and, to avoid creating partitions by >>> hand, to make them in ON BEFORE STATEMENT trigger. Trigger executes >>> successfully (proved that with RAISE NOTICE), but server crashes. > >> The problem here is with the server allowing to create a partition of the >> table being inserted into, inside the table's BEFORE INSERT trigger. >> Generally speaking, the command that's run inside the trigger shouldn't >> have been allowed to proceed if it might change the table's properties >> that the execution of the ongoing command is depending upon. > > Check. > >> I propose the attached to fix that. > > Hmm ... I wonder if we shouldn't do CheckTableNotInUse for *both* cases, > is_partition or no?
Yeah, that would be better robustness-wise, but I couldn't think of a case where not doing CheckTableNotInUse for the !is_partition case would be problematic. Adding an inheritance child doesn't change the relcache content of the parent table, but for partitioning it does. Maybe I'm missing something though.
Attached updated patch adds the check for both cases, although I'm not sure what the error message text added by the patch should look like. Is the following OK?
