Hi Michaël, Am 10.04.2013 22:30, schrieb Michaël Michaud: > Hi, > > Original question was about the Layer Name of Run Datastore Query. > > But Layer Name is a OpenJUMP thing. > There is no restriction about how to write a Layer Name and many > OpenJUMP plugin write layer names with spaces. > > I guess your problem is that this layer name will be used again > when you'll try to save the queried Layer into a Postgis table. > Is that right ?
Yes, that is my problem. I like to avoid errors and quoted identifiers. > 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. ... > To have a more standard table name, I think the Layer Name > should be normalized when proposed in the Table text area of > SaveAsPostgisTable . > But if the user wants to have table names with the same > orthograph as his layer names, he will not appreciate. > > To come back to the Run Datastore PlugIn, I'm now used to > write my query, then copy/paste the (first) table name in the > Layer Name Text field. Not very user friendly, but did not find > a better way. Could do that with a button... > > Michaël > Uwe >> On 10.04.2013 13:41, Uwe Dalluege wrote: >>> Hi, >>> >>> Am 10.04.2013 11:27, schrieb edgar.sol...@web.de: >>>> On 10.04.2013 11:15, Uwe Dalluege wrote: >>>>> Hi, >>>>> >>>>> is it possible to change the >>>>> default Layer Name of >>>>> "Run Datastore Query" >>>>> to a valid SQL table name? >>>>> >>>>> An inexperienced user with SQL >>>>> maybe do not know that >>>>> "New Query Layer" is not a valid >>>>> layername (SQL-Tablename). >>>>> >>>> i'd rather suggest to check & hint so on trying to save the table so user >>>> can rename manually then. because >>>> 1. user has a learning effect then >>> I do not think, that OJ should be a try and error GIS >>> only for a learning effect. >> how do you suppose a db user will learn about naming restrictions then? >> >>> >>>> 2. the name is proper in OJ and not all db's have the same naming >>>> conventions >>> >>> Please tell me a databasemanagementsystem which uses standard SQL >>> and accept blanks inside the tablename. >> why do you expect every DBMS connector to use ANSI SQL? there are several >> SQL dialects out there and used actively as well. >> MYSQL for one supports spaces in table names. >> >> ..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
