On 23 April 2015 at 13:51, Andres Freund <and...@anarazel.de> wrote:
> On April 23, 2015 3:34:07 PM GMT+03:00, Geoff Winkless <
> pgsqlad...@geoff.dj> wrote:
>
> >
> And what's to stop me having "SELECT true
>
> AS
>do" in the where clause (as per your UPDATE objection)?
>
> A syntax error. DO is a reserved keyword. Update is just unreserved (and
> thus can be used as a column label). Ignore is unreserved with the patch
> and was unreserved before. We obviously can make both reserved, but of so
> we have to do it for real, not by hiding the conflicts
>
Sorry, I misunderstood: so it's not the fact that it can't be used as a
column label (because it can) but the fact that it can't then be referenced
within a WHERE clause without quoting
. Which is in itself utterly horrible, but that's a separate argument and I
can at least now understand your point.
So I could end up with
INSERT INTO mytable (somevalue) VALUES (999) ON CONFLICT ('myindex') WHERE
update UPDATE update=1
but I would have to do
INSERT INTO mytable (somevalue) VALUES (999) ON CONFLICT ('myindex') WHERE
"do" UPDATE "do"=1
?
> >Apologies for butting in but can I (as a user) express a preference as
> >a
>
> user against DO?
>
> Sure. If you propose an alternative ;)
>
Maybe I'm misreading it, but isn't index_predicate meant to be inside the
brackets?
http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/on-conflict-docs/sql-insert.html
certainly states that.
It's not one right now. And ignore isn't a keyword at all atm.
>
As I said, it's my personal belief that anyone using keywords (of any
kind) unquoted deserves what they get, but I see your point.
I think I object to the fact that you're talking about adding extra
syntactic sugar to work around a parser-implementation problem, not an
actual syntax problem (since UPDATE SET is unambiguous, isn't it?).
(Please don't top post)
>
Mea culpa. I blame google :)
FWIW "DO IGNORE" just reads disgustingly. If you do finally go down the DO
route, perhaps "DO NOTHING"? :)
Geoff
