On April 23, 2015 3:34:07 PM GMT+03:00, Geoff Winkless <pgsqladmin@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?
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"? :)
