Re: Boolean partitions syntax

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: robertmhaas(at)gmail(dot)com, peter(dot)eisentraut(at)2ndquadrant(dot)com, Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp, sfrost(at)snowman(dot)net, hornschnorter(at)gmail(dot)com, dilipbalaut(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Boolean partitions syntax
Date: 2018-02-05 09:17:52
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


At Fri, 02 Feb 2018 18:04:44 -0500, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <14732(dot)1517612684(at)sss(dot)pgh(dot)pa(dot)us>
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Fri, Feb 2, 2018 at 4:40 PM, Peter Eisentraut
> > <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> >> There might be other options, but one way to solve this would be to
> >> treat partition bounds as a general expression in the grammar and then
> >> check in post-parse analysis that it's a constant.
> > Yeah -- isn't the usual way of handling this to run the user's input
> > through eval_const_expressions and see if the result is constant?

At Mon, 29 Jan 2018 13:21:54 +0900, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote in <6844d7f9-8219-a9ff-88f9-82c05fc90d70(at)lab(dot)ntt(dot)co(dot)jp>
> Partition bound literals as captured gram.y don't have any type
> information attached. They're carried over in a A_Const to
> transformPartitionBoundValue() and coerced to the target partition key
> type there. Note that each of the the partition bound literal datums
> received from gram.y is castNode(A_Const)'d in parse_utilcmds.c.

eval_const_expressions is already running under
transformPartitionBoundValue to resolve remaining coercion. I
suppose we can use AexprConst to restrict the syntax within
appropriate variations. Please find the attached patch.

It allows the following syntax as a by-prodcut.

| create table c4 partition of t for values in (numeric(1,0) '5');

Parser accepts arbitrary defined types but it does no harm.

| create table c2 partition of t for values from (line '{0,1,0}') to (1);
| ERROR: specified value cannot be cast to type double precision for column "a"

It rejects unacceptable functions but the message may look
somewhat unfriendly.

| =# create table c1 partition of t for values in (random());
| ERROR: syntax error at or near ")"
| LINE 1: create table c1 partition of t for values in (random());
| ^
(marker is placed under the closing parenthesis of "random()")

| =# create table c1 partition of t for values in (random(0) 'x');
| ERROR: type "random" does not exist
| LINE 1: create table c1 partition of t for values in (random(0) 'x')...
(marker is placed under the first letter of the "random".)

> Not sure we want to go quite that far: at minimum it would imply invoking
> arbitrary stuff during a utility statement, which we generally try to
> avoid. Still, copy-from-query does that, so we can certainly make it
> work if we wish.
> Perhaps more useful to discuss: would that truly be the semantics we want,
> or should we just evaluate the expression and have done? It's certainly
> arguable that "IN (random())" ought to draw an error, not compute some
> random value and use that. But if you are insistent on partition bounds
> being immutable in any strong sense, you've already got problems, because
> e.g. a timestamptz literal's interpretation isn't necessarily fixed.
> It's only after we've reduced the original input to Datum form that we
> can make any real promises about the value not moving. So I'm not seeing
> where is the bright line between "IN ('today')" and "IN (random())".
> regards, tom lane

The patch leaves the ambiguity of values like 'today' but doesn't
accept arbitrary functions. Howerver, it needs additional message
for errors that never happen since the patch adds a new item in


Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
allow_bool_as_partbound.patch text/x-patch 7.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2018-02-05 09:46:57 Crash in partition-wise join involving dummy partitioned relation
Previous Message Pierre Ducroquet 2018-02-05 08:20:34 Re: JIT compiling with LLVM v9.1