I agree! We should not force people to use a special name-convention! But, IMHO, if we know, from long time of experience, that a table-name like
New Query Layer can cause problems we should not force to use this name by offer them as a good table-name. uwe Am 11.04.2013 13:35, schrieb edgar.sol...@web.de: > thanks, while not the standard document itself, at least they claim to cite > it. > > anyway, i am on par with Michael on that. it should be optional and > implemented on writing to a DBMS connection. > > ..ede > > PS: i am totally with that using alnum and underscore is the most common > denominator and usually safest. however, we should not force people into a > work flow that we deem as the only correct one. after all we provide a tool > and it is not up to us to determine it's usage. > > On 11.04.2013 13:25, Uwe Dalluege wrote: >> Hi Ede, >> >> maybe this helps: >> >> http://pubs.vmware.com/vfabric5/index.jsp?topic=/com.vmware.vfabric.sqlfire.1.0/reference/language_ref/sql_identifiers.html >> >> All I like to say is that >> delimited identifiers >> can cause problems. >> >> If you like delimited identifiers >> use them! >> >> Uwe >> >> Am 11.04.2013 11:19, schrieb edgar.sol...@web.de: >>> On 11.04.2013 08:34, Uwe Dalluege wrote: >>> SNIP >>>> >>>>> There is no restriction too, as tables are created with quoted >>>>> strings which accept any character (but maybe it is not a so >>>>> common habit among DB adm, and I don't know if quoted >>>>> strings for table or column names is part of the SQL standard) >>>>> >>>> >>>> This page tells us something about identifiers: >>>> >>>> http://www.postgresql.org/docs/9.2/interactive/sql-syntax-lexical.html#SQL-SYNTAX-IDENTIFIERS >>>> >>>> ... >>>> SQL identifiers and key words must begin with a letter (a-z, but also >>>> letters with diacritical marks and non-Latin letters) or an underscore >>>> (_). Subsequent characters in an identifier or key word can be letters, >>>> underscores, digits (0-9), or dollar signs ($). Note that dollar signs >>>> are not allowed in identifiers according to the letter of the SQL >>>> standard, so their use might render applications less portable. The SQL >>>> standard will not define a key word that contains digits or starts or >>>> ends with an underscore, so identifiers of this form are safe against >>>> possible conflict with future extensions of the standard. >>>> ... >>>> >>>> I think, this is the SQL standard >>>> but as you say >>>> maybe this is also SQL standard: >>>> >>>> ... >>>> There is a second kind of identifier: the delimited identifier or quoted >>>> identifier. It is formed by enclosing an arbitrary sequence of >>>> characters in double-quotes ("). A delimited identifier is always an >>>> identifier, never a key word. So "select" could be used to refer to a >>>> column or table named "select", whereas an unquoted select would be >>>> taken as a key word and would therefore provoke a parse error when used >>>> where a table or column name is expected. >>>> ... >>> >>> this is /only/ how PostgreSQL handles it. try to get documentation about >>> the ANSI SQL92, which is the most spread. you will find it is diffcult to >>> obtain as you theoretically would have to purchase it against a fee. if >>> you've got a library access i would be interested what really is written >>> there. but even if it is forbidden there it is up to the implementation of >>> the DBMS to dis/allow any character for table names. >>> >>> anyway. most DBMS i know support some kind of quoting or escaping that >>> allows pretty much anything in a table name. would be interesting if the >>> dot "." is forbidden :) >>> >>> btw. interesting bit about the MySQL concept. it makes it depending on the >>> file system the tables are saved on. the file naming conventions >>> essentially apply to how you can name your tables. >>> >>> ..ede >>> >>> ------------------------------------------------------------------------------ >>> Precog is a next-generation analytics platform capable of advanced >>> analytics on semi-structured data. The platform includes APIs for building >>> apps and a phenomenal toolset for data science. Developers can use >>> our toolset for easy data analysis & visualization. Get a free account! >>> http://www2.precog.com/precogplatform/slashdotnewsletter >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> > > ------------------------------------------------------------------------------ > Precog is a next-generation analytics platform capable of advanced > analytics on semi-structured data. The platform includes APIs for building > apps and a phenomenal toolset for data science. Developers can use > our toolset for easy data analysis & visualization. Get a free account! > http://www2.precog.com/precogplatform/slashdotnewsletter > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
