Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Drill >> mail # dev >> Sql Option Statements


Copy link to this message
-
Re: Sql Option Statements
Standard SQL has the following uses of SET as a top-level statement:

SET SCHEMA …
SET ROLE …
SET TIME ZONE ...
SET CATALOG …
SET SESSION COLLATION ...
SET SESSION CHARACTERISTICS …
SET SESSION AUTHORIZATION …
SET NAMES …
SET PATH …

I don’t think it’s wise to allow SET <variable> = <value>. It would clash with these official SET statements.

Instead I think you should have

ALTER [ SYSTEM | SESSION ] SET <variable> = <value>.

A few databases have this kind of syntax. Make the option name is syntactically an identifier, and the option value a literal.

As an identifier, if your option name contains spaces, you must enclose it in double-quotes.

As a literal, valid option values include TRUE (a boolean), NULL, ‘foo bar’ (a character literal), 10.5 (a decimal), INTERVAL ’10:30’ HOURS (an interval literal).

At a stretch, allow ON, OFF (synonyms for TRUE and FALSE) and suffixes k, m, g (e.g. 10k means 10480).

Julian
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB