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

Reply via email to