|From:||Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>|
|To:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>|
|Subject:||Re: using expression syntax for partition bounds|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
>> 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.
|Next Message||Vik Fearing||2019-01-18 09:50:29||Re: Prepare Transaction support for ON COMMIT DROP temporary tables|
|Previous Message||Fabien COELHO||2019-01-18 08:37:26||Re: PSA: we lack TAP test coverage on NetBSD and OpenBSD|