Is the COALESCE a function of the ANSI SQL especification? Is it supported by the major relational databases?
Yes:
https://www.mssqltips.com/sqlservertip/2689/deciding-between-coalesce-and-isnull-in-sql-server/
From the article:
Some think that you need to use COALESCE because it is the only one that adheres to the ANSI SQL standard.
and Yes.
The ISO/ANSI SQL standard specification (ISO/IEC 9075-2:2016(E)) lists CASE and COALESCE as optional features:
F261 CASE expression
F261-04 COALESCE
Yes, COALESCE is defined by the ISO/ANSI SQL standards.
Related
I try to convert mssql query to postgresql query.
mssql query is
CONVERT(VARCHAR, column)
I know postgresql cast is two ways.
1.
CAST(column as VARCHAR)
column::VARCHAR
What's the difference?
Is it ok to use the second method?
Quote from the manual
PostgreSQL accepts two equivalent syntaxes for type casts:
CAST ( expression AS type )
expression::type
The CAST syntax conforms to SQL; the syntax with :: is historical PostgreSQL usage.
(emphasis mine)
So both do the same thing, the cast() being standard SQL, the :: being Postgres specific.
Note that there is a third way of casting (as explained in the manual)
It is also possible to specify a type cast using a function-like syntax:
typename ( expression )
But it's not recommended as the manual says: "Obviously, this is not something that a portable application should rely on"
If my query is
SELECT from FROM myTable;
How can I escape column name 'from'.
I need a way which is applicable to Oracle, MySQL, Teradata and all other systems
Will
SELECT myTable.from FROM mytable;
work on all systems?
The SQL standard is pretty clear: reserved keywords can only be used when they are enclosed in double quotes:
select "FROM" from mytable;
Note that a quoted identifier are also case sensitive. "Foo" and "FOO" are two different names! (whereas Foo and FOO are the same names in standard SQL and most DBMS)
I need a way which is applicable to Oracle, MySQL, Teradata and all other systems
Postgres, Oracle, DB2 (LUW), Firebird, Ingres, HSQLDB, H2, Vertica, HANA and Teradata comply with the standard out of the box.
MySQL needs to convinced to respect the standard by setting sql-mode to ANSI or at least ANSI_QUOTES.
For SQL Server the option QUOTED_IDENTIFIER needs to be set to on.
For Informix you need to set DELIMIDENT to y when connecting through JDBC
But in general you should really avoid the need to use quoted identifiers. Typically you will get in trouble sooner or later by doing that.
Universal method??? not sure about any such but double quote "" is ANSI standard other than that every RDBMS has some specific way of doing so. Moreover you don't need any such universal way if you refrain yourself from using reserve word or keyword for table or column name .. as already suggested in comment
Happy new years, stackoverflow!
I am trying to use some regex functions in bigquery but some of them return error as if I have the name wrong.
SELECT REGEXP_CONTAINS(path, r'^abc$') FROM [tablename]
Query Failed
Error: 2.24 - 2.26: Unrecognized function regexp_contains
Where as if I do a similar regex function, the function text in the editor changes color and the query works.
SELECT REGEXP_EXTRACT(path, r'^abc$') FROM [tablename]
It should work since it's documented in this link.
Does anyone know how to fix this?
BigQuery Legacy SQL and Standard SQL support different set of regular expression functions
Legacy SQL Regular Expression Functions:
REGEXP_MATCH, REGEXP_EXTRACT and REGEXP_REPLACE
Standard SQL Regular Expression Functions:
REGEXP_CONTAINS, REGEXP_EXTRACT, REGEXP_EXTRACT_ALL and REGEXP_REPLACE
So, in your case just make sure you use proper BigQuery SQL dialect
#standardSQL
SELECT REGEXP_CONTAINS(path, r'^abc$') FROM [tablename]
ANSI SQL:2008: Are TRUNCATE or TRUNC a SQL Function?
Where can I find the ANSI SQL:2008?
TRUNCATE "was officially introduced in the SQL:2008 standard."
SQL:2008 "is not freely available. The whole standard may be purchased from the ISO as ISO/IEC 9075(1-4,9-11,13,14):2008."
O'Reilly SQL in a Nutshell (ISBN-10: 0596518846, ISBN-13: 978-0596518844) lists TRUNC() as a "Platform-specific extension."
According to the postgresql docs, yes, this is a standard command. The family of standards documents are linked to from wikipedia, but IMHO these are not very usable in their raw form. YMMV.
I was under the impression that argument-less functions can be called with empty parentheses after the function name, i.e. what some other databases allow to do:
current_timestamp()
Whereas in Oracle, I have to write
current_timestamp
With user-defined functions, this rule doesn't apply (in 11g). I can write both
my_function
my_function()
My question is: Is CURRENT_TIMESTAMP really a true function or should I consider it to be a language construct / pseudo-column of the Oracle SQL dialect (compatible with the SQL standard)? Is there any formal definition about when I can (optionally, mandatorily) add the () and when I have to omit them?
Background-info:
SQL 1992 defines:
<current timestamp value function> ::=
CURRENT_TIMESTAMP [ <left paren> <timestamp precision> <right paren> ]
Derby, HSQLDB, Ingres, Postgres, SQLite, SQL Server behave like Oracle, where there are no parentheses allowed for CURRENT_TIMESTAMP
Sybase SQL Anywhere knows a CURRENT TIMESTAMP function (without parentheses, without underscore)
CUBRID, MySQL, Sybase ASE allow for using CURRENT_TIMESTAMP()
SQL standards back to 1992 refer to CURRENT_TIMESTAMP as both a "time-varying system variable" and a "datetime value function". See, for example, Database Language SQL.
But AFAIK the standards always use CURRENT_TIMESTAMP, never CURRENT_TIMESTAMP(). Using CURRENT_TIMESTAMP() on a compliant dbms should fail with a syntax error.
I'm not sure what the standards have to say about user-defined functions.