Since using Arrays in columns is still more of a NoSQL than RDBMS way of storing a list, I understand that Liquibase doesn't officially support the type. However, when I use the PSQL statements from the docs, I get the following:
<column name="widgets" type="varchar(8)[]" />
Trace output:
liquibase.exception.DatabaseException: org.postgresql.util.PSQLException: ERROR: syntax error at or near "("
...
Caused by: org.postgresql.util.PSQLException: ERROR: syntax error at or near "("
The vary same DDL works as expected when run from the PSQL command line.
It must be a bug of sorts in the PSQL parser. Just adding a space fixes it.
<column name="widgets" type="varchar(8) []" />
Liquibase must be changing the SQL string in some mior way.
Related
I am trying to query from a database called physionet-data.mimiciii_clinical.diagnoses_icd
PostgresSQL returns the following error message:
quan.sql:273: ERROR: syntax error at or near "`"
LINE 132: from `physionet-data.mimiciii_clinical.diagnoses_icd` icd
I think it is caused by the dash. If I change the `for ' the same error comes up
quan.sql:273: ERROR: syntax error at or near
"'physionet-data.mimiciii_clinical.diagnoses_icd'"
Any clue on how to fix that?
You would need to quote that schema name, using double-quotes:
select ...
from "physionet-data".mimiciii_clinical.diagnoses_icd
Note that quoting an identifier makes it case-sensitive. You would need to ensure that the character case the schema was created with matches the one you are using here.
Using identifiers that require quoting is not a good idea in general; as you are fiding out, this requires quoting them every where you use it later on. If that's not too late, I would recommend changing the schema name to a name that does not require quoting.
I'm trying to apply a liquibase changeset in sql format with valid PostgreSQL syntax. The query contains a ? operator and a regexp with ? special character.
When running this query against DB from psql everything works perfect.
When I try to apply this changeset with liquibase, I get an error:
org.postgresql.util.PSQLException: ERROR: syntax error at or near "$1"
Looks like liquibase considers ? a prepared statement argument and fails. I don't have any prepared statements in my query and I don't want liquibase to transform my query to a prepared statement.
I've found a workaround for a ? operator (substituting it with double ?? seems to work, though undocumented), but there is no workaround for regexp.
How can I set liquibase to just run the query against my DB as is?
Found help here
Reference usage with liquibase:
<changeSet id="1234" author="xyz">
<sql>
UPDATE blog
SET blog__metadata = blog__metadata::JSONB - 'someUnwantedKey',
WHERE blog__metadata::JSONB ?? 'someUnwantedKey';
</sql>
</changeSet>
i am using PostgreSQL database for my application. Now i have to import my all databases in it.
I am using this command for importing,
psql -U postgres Employees < dbimport.pgsql
but it is not importing. I have already created the database with name Employees in my PostgreSQL.
Getting Error like,
42601: syntax error at or near "psql"
Please suggest me if i am going wrong.
if you have postgres client installed, probably you have misconfigured environmental variables ($PATH), to find the psql use instructions here: https://stackoverflow.com/a/44106963/5315974
Basically you need to usemlocate (if you have it installed) or just find...
Unrelated, but also I would avoid using mixed case in database name...
Also 42601: syntax error at or near "psql" error code means you try to run psql as SQL statement, which it is not - look into your dbimport.pgsql if you have not SQL there - maybe it is shell (or some other) script?..
The error 42601: syntax error at or near "psql" is a syntax_error from the database not from the terminal, so the value of $PATH is not wrong.
It looks like the file 'dbimport.pgsql' which you are trying to import does not contain the importable data.
Can you confirm, how this backup was taken? Or the content of file 'dbimport.pgsql'.
I am trying to import https://www.yelp.com/dataset/documentation/sql into a PostgreSQL instance. It is having problems with accent marks/backtick. Other than doing a character replace, is there any other way to deal with this?
ERROR: syntax error at or near "PaxHeader"
LINE 1: PaxHeader/yelp_db.sql17 uid=998889796
^
ERROR: syntax error at or near "`"
LINE 1: CREATE DATABASE /*!32312 IF NOT EXISTS*/ `yelp_db` /*!40100 ...
^
ERROR: syntax error at or near "USE"
LINE 1: USE `yelp_db`;
^
ERROR: syntax error at or near "`"
LINE 1: DROP TABLE IF EXISTS `attribute`;
These are typical MySQL syntax issues that PostgreSQL conforms to the standard on and therefore doesn't support. There are a few different converters on GitHub that might help. When I had to do this last, there were tools to convert text dumps. They didn't work perfectly but they got things close enough. Reviewing the tools around today, they tend to assume you have an actual MySQL database, not just a dump file.
So it looks like the appropriate way to address this today is to load the data into MySQL and then move it to PostgreSQL. In this regard you seem to have four options that I can think of for converting the schema and data:
There are tools to convert XML dumps from MySQL and load these into PostgreSQL.
You could set up a foreign data wrapper from PostgreSQL to the MySQL db and then copy the schemas and data in.
You could manually convert the schemas, and then dump/reload the data using an ETL process via CSV.
There are tools to read a live MySQL database and insert the data into PostgreSQL.
I'm trying to load a database into Heroku from a sql file, however I get a syntax error from back quotes / backticks.
heroku pg:psql < backup.sql
Outputs this error:
syntax error at or near "`"
Why is that? Aren't backquotes valid?
I can find/replace them with something else if that would be good to try.
are you restoring from a postgresql system or another db software such mySQL?
can you search your backup.sql file for the back-ticks and post that section of your file?
it would help to know if your back-ticks are in the column field names or in the data portion of the SQL statement.