Re: Boolean partitions syntax

At Wed, 11 Apr 2018 02:33:58 +1200, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote in <CAKJS1f8QAF8bT7ixF21ScE8M3CN0c37xE5PT4XEvnthxete5Ng(at)mail(dot)gmail(dot)com>
> On 3 February 2018 at 12:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?

At least partition bound *must* be a constant. Any expression
that can be reduced to a constant at parse time ought to be
accepted but must not be accepted if not. random() is immutable
but can be reduced to a constant at parse time so it can take a
part of partbound expression freely. I don't think there's a
serious problem this side but docuementaion.

On the other hand view can take either but it is not explicitly
specifiable for its creator. The following two work in different
way for reasons of PostgreSQL internal and we cannot see the
difference until dumping definition.

create view vconstdate as select * from sales where sold_date = 'today';
create view vvardate as select * from sales where sold_date = now()::date;

Maybe we could explicitly control that by having pseudo functions
like eval().

... where sold_date = eval_on_parse('today');
... where sold_date = eval_on_exec('today');

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center