I have 2 PostgreSQL databases. The first one is version 9.1, and the second is version 9.3. They are configured the same way (including setting standard_conforming_strings=off). The following query returns one result on the version 9.1 database but returns nothing when run on the 9.3 database. Why?
select 'WORKS' where 'test.123' < 'test/';
Your databases may have different collation settings, which affects sort order. Check your collation with:
select datname, datcollate from pg_database;
If that's the case, you'll need to drop and recreate your 9.3 database with a collation matching your 9.1 copy.
Related
I'm working with pgAdmin4 and PostgreSQL 9.5.25 on Ubuntu 16.04 (I know it's outdated but I really need to work on it currently).
I can add a new table to my database, however, when I try to add a new column using GUI (Table --> Properties) to an existing table I get this error message:
ERROR pgadmin: Failed to execute query (execute_scalar) for the server #1 - DB:api_dev2 (Query-id: 1319646):
Error Message:ERROR: syntax error at or near "NOT"
LINE 2: ADD COLUMN IF NOT EXISTS is_for_sale boolean DEFAULT Fal...
^
The corresponding SQL query is this
ALTER TABLE IF EXISTS public."Products"
ADD COLUMN IF NOT EXISTS is_for_sale boolean DEFAULT False;
I know that "IF NOT EXISTS" is the source of the problem. When I simply run this query:
ALTER TABLE IF EXISTS public."Products"
ADD COLUMN is_for_sale boolean DEFAULT False;
it works. But why is this "IF NOT EXISTS" is added by pgAdmin4?
ADD COLUMN IF NOT EXISTS is only available in Postgres 9.6 and up. See the documentation for Postgres 9.5.
To address your edit, the version of PostgreSQL you are using is no longer supported - all supported versions support the ADD COLUMN IF NOT EXISTS syntax which is probably why pgadmin assumes it is fine to use it. You could try to use an older version of pgadmin.
As pointed by amazon that PostgreSQL 9.3 is deprecated and need to upgrade our version of PostgreSQL to upper version, we just upgraded our version to 9.4. But after upgrade we are not able to do any save() operation from your Yii 1.1 project locally but the operation is working fine from the server.
When we try to run our project from locally and connect the remote PostgreSQL, we got the below error.
{"error":"SQLSTATE[3F000]: Invalid schema name: 7 ERROR: schema
\"publicubfo06sm23qicfa8kmm0nrv3td81qf928i\" does not
exist","try":"end"}
When I try to see my existing schemas using,
SELECT table_name FROM information_schema.tables
I got 3 values namely 'public','pg_catalog', 'information_schema'
Also want to mention that previously with our version 9.3 we were able to do model operations on Yii 1.1 like $model->save() and then immediately get back the primary key value using $model->id or $model->getPrimaryKey() but now it is not working. Only the $lastId = Yii::app()->db->getLastInsertID('tbl_user_group_id_seq'); way is working now.
Can anyone point me out what is the reason behind it? is something get lost while upgrading from 9.3 to 9.4 like schema, role, sequence or anything else that is causing the errors now to access my RDS from local machine.
In my Postgres 9.6 environment, when I try to execute "MERGE INTO" query, it throws me following error:
ERROR: syntax error at or near "MERGE"
LINE 1: MERGE INTO Stock USING Buy ON Stock.item_id = Buy.item_id W...
^
It seems like it does not support MERGE query. However when I do google, it seems that MERGE is supported by Postgres since version 9.1.
Please tell me whats going wrong here.
Edit: Following are the sources from where I found MERGE support in Postgres.
https://wiki.postgresql.org/wiki/MergeTestExamples
Postgres does not support the MERGE feature.
See https://www.postgresql.org/docs/9.6/unsupported-features-sql-standard.html
F312 | MERGE statement | consider INSERT ... ON CONFLICT DO UPDATE
Also in the latest version (currently 14) it is not supported.
MERGE aka INSERT ... ON CONFLICT DO NOTHING/UPDATE or UPSERT is only available to postgres 9.5 and later:
Note: MERGE is often used interchangeably with the term UPSERT.
UPSERT functionality will be in the PostgreSQL 9.5 release -- see
What's new in PostgreSQL 9.5 MERGE is not in 9.4.5 (the latest
PostgreSQL release as of 2015-10-08)
I am looking for Impala Foreign Data Wrapper for Postgres 9.5. I have tried to figure out from the internet and can only have one reference to https://github.com/lapug/impala_fdw
But it seems the fdw is yet to be completed as per the readme file.
Can someone guide me to any other Impala FDW available which I can use to connect Postgres to Impala?
Since Impala supports JDBC and ODBC, you've got some options.
My jdbc2_fdw fork with 9.5 patches - compiles and able to retrieve results. Not fully tested yet. Incorporates mc-soi's jdbc2_fdw patch for PostgreSQL 9.5 and includes additional changes.
jdbc2_fdw - only works with PostgreSQL 9.4 and earlier
odbc_fdw
I'm using odbc_fdw and heimir-sverrisson's jdbc2_fdw successfully with PostgreSQL 9.4.
PostgreSQL 9.5 changed the API. I just got the jdbc2_fdw working to some degree, but had to do additional patches on the path I mentioned. It allows retrieving results from a foreign table and creating a materialized view on it. More testing is needed. Link shared above.
I'm currently reviewing the usage of indexes in a complex PostgreSQL database. One of the queries that look useful is this
SELECT idstat.schemaname AS schema_name, idstat.relname AS table_name,
indexrelname AS index_name,
idstat.idx_scan AS times_used,
pg_size_pretty(pg_relation_size(idstat.relid)) AS table_size, pg_size_pretty(pg_relation_size(indexrelid)) AS index_size,
n_tup_upd + n_tup_ins + n_tup_del as num_writes,
indexdef AS definition
FROM pg_stat_user_indexes AS idstat JOIN pg_indexes ON (indexrelname = indexname AND idstat.schemaname = pg_indexes.schemaname)
JOIN pg_stat_user_tables AS tabstat ON idstat.relid = tabstat.relid
WHERE idstat.idx_scan < 200
AND indexdef !~* 'unique'
ORDER BY idstat.relname, indexrelname;
It tells me how often the index was used, how much space it uses etc.
However:
I get the database backup from the client site. When I restore the database, the query returns zeros for times_used. I suspect that all indexes are rebuild on restore.
Finally, question:
What is the easiest way to capture (backup) the data from pg_catalog so that actual client data on index use can be restored and analyzed?
Provide an SQL script that the client can run with psql -f report_on_live_db.sql live_db_name . Have it SELECT the desired data.
Alternately, you might be able to get a raw file-system level copy of the client database from the client and then fire it up on your local machine. This will only work if you can run PostgreSQL on the same operating system and architecture; you can't use a 64-bit PostgreSQL to access a 32-bit database, nor can you use a Linux PostgreSQL to access a Windows or BSD database. The same PostgreSQL major version must be used; you can't use 9.1 to access a 9.0 database or vice versa.