On Wed, Jan 8, 2014 at 10:27 PM, Alvaro Herrera
<alvherre@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