On Wed, Jan 8, 2014 at 10:27 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > 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}
Why not: "if_not_exists": true/false -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers