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.
Related
I came across a SQL query which looks different from the traditional SQL syntax. Can someone please tell me how is it functionally different from the one which we are used to? And also, whats this SQL known as?
SELECT activity_hour AT TIME ZONE <Parameters.Time Zone> "activity_hour",
INITCAP(domain_entity) "domain_entity",
bytes_received,
bytes_sent,
bytes_total
FROM recent_subscriber_activity("hour_from$" => <Parameters.Pick a Date>::DATE AT TIME ZONE <Parameters.Time Zone>,
"hour_to$" => <Parameters.Pick a Date>::DATE AT TIME ZONE <Parameters.Time Zone> + INTERVAL '36 hours,
domain_category_grouping$ => TRUE, connection_id$ => <Parameters.connection_id>,domain_category_filter$ => <Parameters.Category>)```
This is PostgreSQL syntax for some features that are either part of newer revisions of the SQL standard, or else they are proprietary extensions to the SQL standard added by PostgreSQL because they thought they would be useful.
Which SQL features are standard depends on the which year's version of the SQL standard are followed. The SQL standard allows vendors to invent their own extensions to standard SQL.
Some of the parts of the syntax above that you might not recognize are:
Using a function as a query source is described here:
https://www.postgresql.org/docs/current/xfunc-sql.html#XFUNC-SQL-TABLE-FUNCTIONS
Passing function arguments with the => syntax is described here:
https://www.postgresql.org/docs/current/sql-syntax-calling-funcs.html#SQL-SYNTAX-CALLING-FUNCS-NAMED
Type conversions with the :: operator is described here:
https://www.postgresql.org/docs/current/sql-expressions.html#SQL-SYNTAX-TYPE-CASTS
The AT TIME ZONE operator is described here:
https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-ZONECONVERT
All brands of SQL database have their own vendor-specific syntax and enhanced features. It's worthwhile to study the documentation of the brand of SQL database you use, to get accustomed to their features.
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.
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
On searching msdn, I found a built-in function called HASHBYTES(). Not sure if that can be used to get a result that DBMS_UTILITY.get_hash_value() gives in oracle.I am using SQL Server 2008. Thanks in advance.
HASHBYTES is close, but uses presets for certain algorithms (e.g. SHA1 or MD5)
You can't choose the base or length like you can with DBMS_UTILITY.GET_HASH_VALUE()
You may have to roll your own to emulate it exactly but I'd see this as a backwards step...
Comparison in SQL built-in functions in Oracle and SQL Server on below given link
http://dotnet-bm.blogspot.in/2013/08/comparison-in-sql-built-in-functions-in.html
Across various SQL dialects, what string representation for a Date and/or DateTime would be most likely to be interpreted correctly? Is there an SQL Standard? Are the two answers identical or similar?
EDIT:
For suggestions, can we all please comment with any known SQL dialects that don't comply?
I would bet the ISO 8601 date time standard would most likely be the one.
'YYYY-MM-DDThh:mm:ssTZD'
Or maybe a slight variation:
'YYYY-MM-DD hh:mm:ss'
http://www.w3.org/TR/NOTE-datetime
If you want to be portable across databases, maybe you should consider abstracting everything away using something like ADO or OTL. Pretty much all databases support ODBC connections, and you could just use something like OTL's datetime container to write and read dates.
There's also DATE'2014-07-02', which is accepted by Oracle, DB2, MySQL, and Teradata, but not MS SQL or PostgreSQL.