Closed mikepizzo closed 7 years ago
Proposal is to not introduce a way to specify whether or not a table is open at this time.
Feedback suggests sources will support open or closed tables, but not give the application the ability to choose upon creation. We can add a syntax if/when sources support giving the application the choice of open/closed. In the meantime, if a source has the choice they could simply default to open.
Should we add a way for the client to specify whether or not they want a table/type created as open?
A previous draft proposed an "open" escape clause (see below). However, it is unclear how this would work as most (all?) data stores only support open or closed tables. i.e., a relational store will always create a "closed" table (unless the driver or some other layer emulates an open table by creating a side key/value pair table) and a non-sql store will always create an open table. Unless a data store can support both, there's not really any use in having syntax to express whether the client wants it open or not, other than to return an error if the client requests the table be open against a relational store, or not be open against a non-sql store.
Proposal for Open escape, if we did decide to add it:
3.9.6.1 Open Escape Clause
ODBC adds a new ODBC-open-escape clause that can be specified when creating a type or a table to specify that an instance of the type, or a row within the table, can have additional dynamic columns not specified in the definition:
ODBC-open-escape ::= ODBC-esc-initiator open ODBC-esc-terminator
For example:
Tables created with the ODBC-open-escape clause can have an empty column list, in which case all of the columns are unschematized: