Re: using expression syntax for partition bounds

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>
Cc: pgsql-hackers(at)postgresql(dot)org, tgl(at)sss(dot)pgh(dot)pa(dot)us
Subject: Re: using expression syntax for partition bounds
Date: 2019-01-18 08:50:56
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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.


Attachment Content-Type Size
v9-0001-Allow-generalized-expression-syntax-for-partition.patch text/plain 35.5 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
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