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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers