Why not use UPDATE instead of OPERATE ?

[JulienPalard]

Some random propositions to stick more to a valid SQL syntax, and keeping dors open for future modifications:

Actual syntax: SELECT WHERE COLOR = #FF0000FF; OPERATE SET COLOR = #00FF00FF;

Using UPDATE: UPDATE color = #00FF00FF WHERE COLOR = #FF0000FF;

Or, even more SQLish, why not specify the aspect you want to change as a table name:

UPDATE colors SET color = "#00FF00FF" WHERE color = "#FF0000FF";

enabling modifications on other aspect in the future, like EXIF ?

Or, why not using fields, I mean, the table color "obviously" have the following schema: x, y, r, g, b, a so:

UPDATE colors SET r = 0xFF, g = 0, b = 0xFF WHERE r BETWEEN 0xF0 AND 0xFF

Opening the possibility to change a single color, or just the opacity, or use math, and provide new fields in the future for other color planes like YUV.

[JulienPalard]

With the UPDATE syntax can even change colors according to other color, even position:

UPDATE colors SET r = (x / 100) % 255, g = (y / 50) % 255;

I bet the output is particularly ugly, but I made my point ^-^

[Phildo]

I've answered this in another thread here (and on reddit, HN, etc...), but the gist is "more sql-ish" isn't really a goal for me. I find some of the practices within SQL to not really be ideal (ie, setting a value before picking out what you're setting...). Further, the idea to separate "colors" into the equivalent of a table functions to map this better to traditional SQL, but has no other purpose. There isn't a ton of use to consider colors as its own table. And for your latter post, you can already do that!

OPERATE SET r = (col / 100) % 255; OPERATE SET g = (row / 50) % 255;

I am however looking for more terse ways to express multiple operates (the comma syntax like within your latter query looks promising...).

All that said, thanks for the suggestions! Like I said, you're not the only one to suggest this, so it's definitely got some more brewing time in my head before I figure out how to move forward...

Thanks!

[JulienPalard]

I see a lot of possibilities to use a table name, here are some tables examples:

• EXIF
• XMP
• IPTC
• JFIF
• You got it...
• info (Containing width, height, name, size, compression_mode, format, color_space, bit_depth, chroma_subsampling, ... you got it)
• Why not exposing each color representation: colors_RGB, colors_RGBA, colors_YUV, colors_YIQ, colors_YDbDr, etc .... ?
• I'm sure in the future we'll have ideas to index an image with other metrics than X, Y, so other tables to hit them may be usefull.

As a matter of fact, I don't like the OPERATE keyword, and don't understand where is the gain of inventing a new keyword instead of using the already existing UPDATE.

I mean, everyone know, understand, and can fluently write UPDATE statements, but they'll have to read your documentation to learn the OPERATE statement, why ?

[Phildo]

I guess I should keep this thread open to centralize discussion on this, as it seems there is more discussion to be had.

With your request to add "tables" as essentially organizational namespaces, I'm still hesitant. I'd like to push hard to keep things simple- if the interface to this gets complex as photoshop, you really ought just be using photoshop. I'd ideally like a quick skim to be able to pick up two or three "truths" about this language ("ok, so semicolon separated statements, an optional init, n procedures which consists of n selects and n operates, ok got it") and you really know everything there is to know. Any further functionality (eg, "how do I blur") is on the user. Who knows. Maybe that philosophy still has room to evolve.

And with switching OPERATE to UPDATE, I'm not super against it. OPERATE makes it clear that the syntax is different (rather than "Why doesn't UPDATE SET r = 255 WHERE row = 100 work?!?!"). But again, still up for discussion.

Thanks again for your input!

[infogulch]

I also dislike the OPERATE syntax, but I don't think UPDATE is the right solution. I see two perspectives on this.

1. If you filter with a WHERE clause, it still includes the filtered out pixels, it just doesn't operate on them; similar to an UPDATE statement in SQL.
2. But if you have an output target, you're not really modifying/UPDATE-ing the original, so "update" is misleading. (And it would be unhelpful to force the syntax to describe where the output is going; this should remain a command argument.)

Neither select nor update fit pixQL's model perfectly from a SQL background, but in my opinion #2 is a stronger argument and select should stay, with some modifications. I want to propose an alternate syntax for SELECT; I suppose I'll do that on a different issue.