Thanks for the comments.
On 2019/01/18 16:48, Peter Eisentraut wrote:
>> How about the following note in the documentation:
>>
>> + Although volatile expressions such as
>> + <literal><function>CURRENT_TIMESTAMP</function></literal> can be used
>> + for this, be careful when using them, because
>> + <productname>PostgreSQL</productname> will evaluate them only once
>> + when adding the partition.
>
> I don't think we have to phrase it in this warning way. Just say that
> volatile expressions are evaluated at the time of the DDL statement.
OK, then just this:
+ Even volatile expressions such as
+ <literal><function>CURRENT_TIMESTAMP</function></literal> can be used.
>> Sorry but I'm not sure how or what I would test about this. Maybe, just
>> add a test in create_table.sql/alter_table.sql that shows that using
>> volatile expression doesn't cause an error?
>
> Possibilities: Create a range partition with current_timestamp as the
> upper bound and then in a separate transaction insert current_timestamp
> and have it appear in the default partition. Or create list partition
> with session_user as one partition's value and then insert session_user
> and have it appear in that table. Or something like those.
OK, added a test that uses current_timestamp.
>> So, should the "name" type's collation should simply be discarded in favor
>> of "POSIX" that's being used for partitioning?
>
> In that specific case, yes, I think so.
>
>>> What we don't want is someone writing an explicit COLLATE clause. I
>>> think we just need to check that there is no top-level COLLATE clause.
>>> This would then sort of match the logic parse_collate.c for combining
>>> collations.
>>
>> Maybe I'm missing something, but isn't it OK to allow the COLLATE clause
>> as long as it specifies the matching collation as the parent?
>
> Yes, that should be OK.
Alright, I've included a test that uses cast expression in partition bound.
Updated patch attached.
Thanks,
Amit
