At Wed, 11 Apr 2018 02:33:58 +1200, David Rowley <david.row...@2ndquadrant.com> wrote in <cakjs1f8qaf8bt7ixf21sce8m3cn0c37xe5pt4xevnthxete...@mail.gmail.com> > On 3 February 2018 at 12:04, Tom Lane <t...@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?
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