| From: | Joshua Yanovski <pythonesque(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-bugs(at)postgresql(dot)org |
| Subject: | Re: BUG #9227: Error on SELECT ROW OVERLAPS ROW with single ROW argument |
| Date: | 2014-02-18 19:25:54 |
| Message-ID: | CABz-M-HQRbEFdN5WeBAMHyfVdN8ERCwJiYXTy1iA89AtTvZ9iA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> Hmm ... interesting idea, but I don't think it answers any of the
> fundamental issues about comparison semantics (ie, how much do we
> care if "var" is promoted differently in the two clauses).
My first thought was that it essentially would work as you describe
above--if the expression is volatile, evaluate the argument first and
then evaluate the expression, otherwise replace the parameter within
the subexpression. But then I realized that you didn't actually say
that is what the BETWEEN node would be doing :) I suppose any extra
logic would have to be present in some translation function to deal
with the let node, so effectively it would be special-cased anyway.
>
> Also, as a grammar translation target for BETWEEN it would be a pretty
> bad choice, because now views that had been defined in a perfectly
> SQL-compliant manner would print out with very-PG-specific syntax.
> The existing translation is nasty because of the double eval issue,
> but at least what we print is standard SQL.
>
> regards, tom lane
That's a good point, I suppose I'll just have to wait for this feature
to be added to the SQL standard :)
--
Josh
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2014-02-18 20:52:37 | Re: BUG #9161: wal_writer_delay is limited to 10s |
| Previous Message | Tom Lane | 2014-02-18 19:20:20 | Re: BUG #9161: wal_writer_delay is limited to 10s |