On 01/09/2014 04:42 AM, Alvaro Herrera wrote:
> If there's a NULL element when expanding an object, the whole thing
> expands to empty. For example, if no AUTHORIZATION
> clause is specified, "authorization" element is still there, but the
> "authorization_role" element within it is NULL, and so the whole
> AUTHORIZATION clause expands to empty and the resulting command contains
> no authorization clause.
I'd like to see this applied consistently to argument-less clauses like
IF NOT EXISTS too. So the same rules apply.
> IF NOT EXISTS is handled by defining it to either the string IF NOT
> EXISTS or to empty if no such clause was specified.
I'm not keen on this bit. It puts clauses of syntax into value strings
other than the special "output" key. Those keys aren't easily
distinguished from user data without clause specific knowledge. I'm not
keen on that.
Instead, can't we use your already proposed subclause structure?
{"authorization":{"authorization_role":"some guy", "output":"AUTHORIZATION
%i{authorization_role}"},"if_not_exists":{"output": "IF NOT EXISTS"},"name":"some schema","output":"CREATE SCHEMA
%{if_not_exists}%i{name} %{authorization}"}
i.e. "if_not_exists" becomes an object. All clauses are objects, all
non-object values are user data. (right?). If the clause is absent, the
"output" key is the empty string.
The issue with that (and with your original proposal) is that you can't
tell what these clauses are supposed to be if they're not present in the
original query. You can't *enable* "IF NOT EXISTS" without pulling
knowledge of that syntax from somewhere else.
Depending on the problem you intend to solve there, that might be fine.
If it isn't, then instead there just needs to be a key to flag such
clauses as present or not.
{"authorization":{"authorization_role":"some guy", "output":"AUTHORIZATION
%i{authorization_role}"},"if_not_exists":{"output": "IF NOT EXISTS" "present": true},"name":"some
schema","output":"CREATESCHEMA %{if_not_exists} %i{name} %{authorization}"}
Am I just over-complicating something simple here?
My reasoning is that it'd be good to be able to easily tell the
difference between *structure* and *user data* in these query trees and
do so without possibly version-specific and certainly
syntax/clause-specific knowledge about the meaning of every key of every
clause.
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services