column_name is of type int[]
SELECT unnest(column_name) FROM table_name
The above query works on postgresql but not on hsqldb, even with sql.syntax_pgs=true
Hsqldb versions tried : 2.2.9 and 2.3.0
The sql that works in hsqldb is
SELECT x FROM table_name, unnest(column_name) y(x)
x and y are NOT columns of this table.
HSQLDB tries to emulate PostgreSQL's syntax and features, but like most emulations it is imperfect.
IIRC, one of the things it has a hard time with is PostgreSQL's quirky use of set-returning functions in the SELECT clause.
Use of SRFs in the SELECT clause is a weird PostgreSQL extension that's deprecated in favour of SQL-standard LATERAL queries anyway. The alternate formulation you showed:
SELECT x FROM table_name, unnest(column_name) y(x);
is the correct and preferred form. So just use that.
In general, testing on one DB then deploying to another is a recipe for pain. I strongly suggest just setting up a local PostgreSQL instance for testing instead.
Related
I use PostgreSQL exclusively. I have no plans to ever change this. However, I recognize that other people are not me, and they instead use MySQL, MS SQL, IBM SQL, SQLite SQL, Oracle SQL and ManyOthers SQL. I'm aware that they have different names in reality.
My queries look like:
SELECT * FROM table WHERE id = $1;
UPDATE table SET col = $1 WHERE col = $2;
INSERT INTO table (a, b, c) VALUES ($1, $2, $3);
My database wrapper functions currently support only PostgreSQL, by internally calling the pg_* functions.
I wish to support "the other databases" too. This would involve (the trivial part) to make my wrapper functions able to interact with the other databases by using the PHP functions for those.
The difficult part is to reconstruct the PostgreSQL-flavor SQL queries from the application into something that works identically yet will be understood by the other SQL database in use, such as MySQL. This obviously involves highly advanced parsing, analysis and final creation of the final query string. For example, this PostgreSQL SQL query:
SELECT * FROM table WHERE col ILIKE $1 ORDER BY random() LIMIT 1;
... will be turned into WeirdSQL like this:
SELECT * FROM table WHERE col ISEQUALTOKINDA %1 ORDER BY rnd() LIMIT 1;
I don't require support from any other input SQL flavor than PostgreSQL, but the output must be "all the big SQL database vendors".
Has anyone even attempted this? Or is it something that is never gonna happen as free software but might exist as a commercial offering? It sounds like it would be a thing. It would be insanely useful, and "crazier" projects have been attempted.
jOOQ is a Java library that aims to hide differences between databases. It has its own SQL grammar which tries to be compatible with everything (but parameter markers must be the JDBC ?), and generates DB-specific SQL from that.
There is an online translator, which generates the following from your query for Oracle:
select *
from table
where lower(cast(col as varchar2(4000))) like lower(cast(:1 as varchar2(4000)))
order by DBMS_RANDOM.RANDOM
fetch next 1 rows only
ODBC uses its own syntax on top on the database's syntax. ODBC drivers are required to convert ODBC parameter markers (?) to whatever the database uses, and to translate escape sequences for certain elements that are likely to have a non-standard syntax in the DB (time/GUID/interval literals, LIKE escape character, outer joins, procedure calls, function calls).
However, most escape sequences are optional, and this does not help with other syntax differences, such as the LIMIT 1.
ODBC drivers provide a long list of information about SQL syntax details, but it is the application's job to construct queries that conform to those restrictions, and not all differences can be described by this list. In practice, most ODBC applications restrict themselves to a commonly supported subset of SQL.
I'm reviewing log of executed PostgreSQL statements and stumble upon one statement I can't totally understand. Can somebody explain what PostgreSQL actually do when such query is executed? What is siq_query?
select *
from siq_query('', '21:1', '', '("my search string")', False, True, 'http://siqfindex:8080/storediq/findex')
I'm running PostgreSQL 9.2
siq_query(...) is a server-side function taking 7 input parameters (or more). It's not part of any standard Postgres distribution I know (certainly not mainline Postgres 9.2), so it has to be user-defined or part of some extension you installed. It does whatever is defined in the function. This can include basically anything your Postgres user is allowed to do. Unless it's a SECURITY DEFINER function, then it ca do whatever the owner of the function is allowed to do.
The way it is called (SELECT * FROM), only makes sense if it returns multiple rows and/or columns, most likely a set of rows, making it a "set-returning function", which can be used almost like a table in SQL queries.
Since the function name is not schema-qualified, it has to reside in a visible schema. See:
How does the search_path influence identifier resolution and the "current schema"
Long story short, you need to see the function definition to know what it does exactly. You can use psql (\df+ siq_query), pgAdmin (browse and select it to see its definition in the SQL pane) or any other client tool to look it up. Or query the system catalog pg_proc directly:
SELECT * FROM pg_proc WHERE proname = 'siq_query';
Pay special attention to the column prosrc, which holds the function body for some languages like plpgsql.
There might be multiple variants of that name, Postgres allows function overloading.
We have an old Flyway database update
UPDATE plays SET album = (regexp_matches(album, '^6,(?:(.+),)?tv\d+'))[1]
...that runs fine with any Postgres version from 9.2 to 9.6 but fails with latest Postgres 10. Happens even when ran directly without any JDBC.
ERROR: set-returning functions are not allowed in UPDATE
Is there a backwards incompatibility I didn't notice from version 10 release notes? Is there a workaround?
This is untested, but should work in all PostgreSQL versions:
UPDATE plays SET album = substring (album FROM '^6,(?:(.+),)?tv\d+');
I had a more general problem where I needed the second match from a regex.
The solution was a nested subselect
SET my_column = (SELECT a.matches[2] from
(SELECT regexp_matches(my_column, '^(junk)?(what_i_want)$') matches) a)
Or modify the regex to return one group and apply #LaurenzAlbe 's answer:
SET my_column = substring (my_column FROM '^junk?(what_i_want)$')
There may be cases where modifying the regex is not ideal.
The original was of the form
SET my_column = regexp_matches(my_column, '^(junk)?(what_i_want)$')[2]
Where junk and what_i_want were fairly complex rexex fragments.
What I'm mostly doing these days is converting an Oracle SQL database into a PostgreSQL (9.1.6) database.
The most common issues that I tend to come across are as follows:
1. decode --> case when
2. nvl --> coalesce
3. (+) --> outer join
4. connect by prior --> connectby function with tablefunc contrib module.
5. merge into --> ???
etc...
I am currently skimming through the PostgreSQL manual and funnily enough there seems to be no MERGE INTO statement (or any direct substitutions for it).
I am aware that PL/pgSQL could be used as an alternative but that would mean a lot of extra workload for me. Is there something that I'm missing about this?
There is no simple replacement, and certainly not for 9.1.
The best option is to upgrade to 9.2 and look at writeable CTE's. These allow you to multi-stage write operations in a similar manner. For example, you could:
WITH up (UPDATE foo set bar = 'baz' where id > 1000
returning id)
INSERT INTO foo(id, bar)
SELECT s, 'baz'
FROM generate_sequence(1001, 10000) s
WHERE s NOT IN (select id from up);
Which is the fastest way to search within string in PostgreSQL (case insensivity):
SELECT col FROM table WHERE another_col ILIKE '%typed%'
or
SELECT col FROM table WHERE another_col ~* 'typed'
How can I turn on showing the time which query need to return results? Something like is on default in mySQL (I am thinking about CLI client).
Both queries are the same, PostgreSQL rewrites ILIKE to ~*. Check the results from EXPLAIN to see this behaviour.
I'm not sure about your question, but the psql-client can show you some timing of the query, using \timing.
Regarding the timing:
One solution is to use the switch for psql that Frank has already mentioned.
When you use EXPLAIN ANALZYE it also includes the total runtime of the query on the server.
I prefer this when comparing the runtime for different versions of a query as it removes the network from the equation.