Re: Boolean partitions syntax - Mailing list pgsql-hackers

From David Rowley
Subject Re: Boolean partitions syntax
Date
Msg-id CAKJS1f8QAF8bT7ixF21ScE8M3CN0c37xE5PT4XEvnthxete5Ng@mail.gmail.com
Whole thread Raw
In response to Re: Boolean partitions syntax  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Boolean partitions syntax  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
On 3 February 2018 at 12:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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())".

I see there's been some progress on this thread that's probably gone a
bit beyond here without the discussion about the desired semantics.

To kick that off, I'm wondering, in regards to the comment about
'today' vs random(); how does this differ from something like:

CREATE VIEW ... AS SELECT ... FROM ... WHERE datecol = 'today'; ?

In this case 'today' is going to be evaluated during the parse
analysis that's done during CREATE VIEW. Why would partitioning need
to be treated differently?

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Date:
Subject: Re: Transform for pl/perl
Next
From: David Rowley
Date:
Subject: Re: Boolean partitions syntax