PostgreSQL: I want to know the difference of 'cast' - sql

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"

Related

Postgres COLLATION FOR

I have tried the function collation for(argument) which is described in the PostgreSQL documentation. But when I try to execute the query which is given in the same PostgreSQL documentation, I get an error. Actually, the statement that I ran was
SELECT collation for ('sample') FROM pg_description LIMIT 1;
It could be better if someone gives the exact correct query and the correct parameters for the function.
What is the use case of this function?
If the function name was wrong, please give me the correct function name.
Strictly speaking, COLLATION FOR is not a "function", but a syntax element of SQL. The underlying function in Postgres is pg_collation_for().
All required information is in the manual, even for your outdated version Postgres 9.5. Search for "collation for" on that manual page and you'll find an example with explanation.
But it's more clearly documented in the current version (quote from pg 15):
Returns the name of the collation of the value that is passed to it.
The value is quoted and schema-qualified if necessary. If no collation
was derived for the argument expression, then NULL is returned. If
the argument is not of a collatable data type, then an error is
raised.
Bold emphasis mine.
Basically, only string types like text and varchar are collatable.
No error should happen for the example query from the manual as pg_description.description is type text. But you ran a different one:
SELECT collation for ('sample') FROM pg_description LIMIT 1;
Which can be shortened to just:
SELECT collation for ('sample');
'sample' is an untyped string literal, i.e. type "unknonwn", but it will be coerced to text by default, so it should not error out, either.

Use Redshift query result as to_char format

Inspired by the slected answer to Declare a variable in RedShift I am trying to use a query result as the format value in a to_char function call:
WITH tmp_variables as (
select 'YYYY-MM-DD' as date_format
)
SELECT to_char(OrderDate, (SELECT date_format FROM tmp_variables)) FROM Orders
But I am getting an error
TO_CHAR parameter: Second input must be a string literal
How can the tmp_variables's date_format value be used as a to_char format without getting an error or is there an alternative to using to_char where this would work?
SELECT is a SQL operator that work upon data. SQL is compiled before it can operate on data. The basic answer is that this won't work as written.
What you are trying to achieve isn't clear in the question - change date output format for some reason for some set of queries but not others? In the general case you will need to modify the SQL that goes to the compiler which will mean reading some configuration and merging this into the SQL text. If the use case is more limited there may be another way to achieve the desired result but only within some set of limitations.
Some possibilities - You could set a SQL variable with the format literal. Your client can read info and modify the query itself if it is capabile. A stored procedure could be used. A SQL modifier (pg_bouncer?) could live between the client and the cluster and substitute the string based on some other factors. Each of these has limitations and costs.
If you can describe the use case it could generate different / better ways.

SQL cast target types: standardized?

SQL function
cast(expression as type):
It is ANSI standard. Is the type standardized? what types are allowed? Are they different from database to database?
Looked at the MySQL and others. MySQL has signed/unsigned, others has INT.
CAST() is ANSI standard. Off the top of my head, ANSI data types are things like:
DECIMAL/NUMERIC(scale, precision)
VARCHAR()/CHAR()
DATE/TIME/DATETIME/INTERVAL
DOUBLE PRECISION/FLOAT
BIGINT/INT/SMALLINT
MySQL changes the syntax a bit. So, UNSIGNED and SIGNED are used instead of INT. And CHAR is used for all the character types. Other databases have their own modification for CAST(). For instance Google BigQuery uses string instead of the character types.

REGEXP_CONTAINS not recognized

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]

Is there a Postgres equivalent to Oracle %TYPE?

In Oracle, if I needed to declare something with the same type as another column, I can simply use %type.
copiedType OTHER_TABLE.COLUMN_NAME%TYPE
Is there an equivalent operator in Postgres? (I'm using 9.4.1)