Craig Ringer escribió:
> 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.
Hmm. This seems like a reasonable thing to do, except that I would like
the "output" to always be the constant, and have some other way to
enable the clause or disable it. With your "present" boolean:
so
"if_not_exists": {"output": "IF NOT EXISTS", "present": true/false}
In fact, I'm now wondering whether this is a better idea than not
emitting anything when some element in the output expands to NULL; so it
would apply to "authorization" as well; if the command includes the
clause, it'd be
{"authorization":{"authorization_role":"some guy", "present": true,
"output":"AUTHORIZATION%i{authorization_role}"},
and if there wasn't anything, you'd have
{"authorization":{"authorization_role": null, "present": false,
"output":"AUTHORIZATION%i{authorization_role}"},
so if you want to turn it on and it wasn't, you need to change both the
present boolean and also set the authorization_role element; and if you
want to turn it off when it was present, just set present to false.
> Am I just over-complicating something simple here?
I think it's a fair point.
> 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.
Sounds reasonable.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services