Working with PostgreSQL, DataGrip converts all names of created tables/columns to lowercase. How to disable it and keep original formatting? I prefer PascalCase.
It happens even if I run a SQL command manually in DataGrip console:
create table FooBar();
so the table foobar is created in db. I searched across the web and found nothing. I suppose it is not a PostgreSQL problem because pgAdmin3 doesn't change anything when it's doing the same things.
My environment:
Windows 7 Pro
DataGrip 2016.3.4
PostgreSQL 9.4
This is a Postgres feature, DataGrip has nothing to this issue.
If you want "PascalCaseIdentifiers" you have to use double quotes.
Identifiers without quotes are case-insensitive. They are automatically converted to lower case.
Read about details in the documentation.
pgAdmin3 doesn't change anything when it's doing the same things.
Quite the opposite, pgAdmin3 adds double quotes when e.g. an identifier contains capital letters (see the last tab SQL in New table... dialog).
In my (and not only my) honest opinion, using quoted identifiers is in general a very bad idea. It simply creates more problems then they are worth it.
Related
I'm using DataGrip to work on a Redshift cluster, which contains a bunch of databases, and error highlighting seems to have gone a bit weird. Let's assume I have schema_1.table_a in database dev and schema_2.table_b in database test on the same cluster. If I connect to dev and write the query:
select * from schema_2.table_b the schema.table reference is highlighted (correctly) as an out of scope error.
However, if I connect to database test and write the query:
select * from schema_1.table_a there is no error highlighting and DataGrip offers to autocomplete the reference. At runtime, the query unsurprisingly throws an error, since test doesn't contain that schema or table.
I find this especially weird because it only affects one database connection. Extending this example, test behaves oddly, but prod, scratch etc. all behave as expected, highlighting similar out of scope errors.
Is there some database scope setting that I've accidentally changed? Driving me mad trying to debug code as I'm putting it into production.
Deleting the Redshift connection and creating a new one does not affect the behaviour; perhaps this is something to do with postgres / Redshift?
Currently DataGrip performs broader lookup for object names in console.
It resolves unqualified names both to database/schema you've configured in data source settings and database/schema you've connected to in console.
The reason is simple: we wanted queries to default schema, which are already written, to be highlighted even when you switch schema (imagine all your code becoming yellow at once).
But looks like it don't suite well for PG databases.
We want to make it configurable. Please watch DBE-6456
I read up several web pages, all spoke about upgrading from Postgres pre-9.0 edition to post-9.1 edition.
www.peterbe.com/plog/postgres-collation-citext-9.1
servoytipsfromsovan.wordpress.com/2014/08/20/migrating-postgres-sql-from-v9-0-to-latest-version/
nandovieira.com/using-insensitive-case-columns-in-postgresql-with-citext
stackoverflow.com/questions/15981197/postgresql-error-type-citext-does-not-exist
databasecm.blogspot.sg/2015/03/where-do-you-find-citext-module-in.html
dba.stackexchange.com/questions/17609/how-do-i-resolve-postgresql-error-no-collation-was-derived-for-column-foo-w
In my case, I upgraded from 9.4 to 9.5. The issue for me is, some database threw the error (as stated on the title) whenever I run a SELECT query yet some don't. I setup a separate test server with 9.4, the query runs well.
I do not need to compare case insensitive. In postgres 9.4, I did not load citext too. In fact all my string comparisons are to be case sensitive unless I use "ILIKE". I also loaded citext individually to ALL the databases in the server.
What information do I need to provide to you so that I can find out why some database works, some don't. And how do I solve the problem I encountered.
Our application successfully communicates with various databases (MSSQL, Oracle, Firebird) via ADO, that's why I'm trying to use ADO to add the PostgreSQL option to our software. I use standard PostgreSQL ODBC provider. All was fine until I faced with the problem with the large TEXT fields. When I use Unicode version of the provider and try to get TEXT field AsString, the application is just crushed with EAccessViolation in method RemoveMediumFreeBlock(). ANSI version works, but it cuts the content of the field (I guess the characters besides default 8190 LongVarChar limit). Small TEXT fields are read OK.
Could you suggest me what to do with this issue?
Is there the better option to work with PostgreSQL via ADO in Delphi?
The project which I am working now is upgrading the database from mysql to postgreSQL in Zend framework. I had migrated the database to PostgreSQL through "ESF Database Migration Toolkit". How ever the field names like "Emp_FirstName", "Emp_LastName" etc are stored in PostgreSQL as "emp_firstname" and "emp_lastname". This caused Errors in code. However when I updated the filed in PostgreSQL to Emp_FirstName it showing error
********** Error **********
ERROR: column "Emp_FirstName" does not exist
SQL state: 42703
Character: 8
Is it possible to give filed name exactly like in MYSQL?
The migration tool isn't "double quoting" identifiers, so their case is being flattened to lower-case by PostgreSQL. Your code must be quoting the identifiers so they're case-preserved. PostgreSQL is case sensitive and case-flattens unquoted identifiers, wheras MySQL is case-insensitive on Windows and Mac and case-sensitive on *nix.
See the PostgreSQL manual section on identifiers and keywords for details on PostgreSQL's behaviour. You should probably read that anyway, so you understand how string quoting works among other things.
You need to pick one of these options:
Change your code not to quote identifiers;
Change your migration tool to quote identifiers when creating the schema;
Hand migrate the schema instead of using a migration tool;
Fix the quoting of identifers in the tool-generated SQL by hand; or
lower-case all identifiers so it doesn't matter for Pg
The last option won't help you when you add Oracle support and discover that Oracle upper-cases all identifiers, so I'd recommend picking one of the first four options. I didn't find a way to get the migration tool to quote identifiers in a quick 30second Google search, but didn't spend much time on it. I'd look for options to control quoting mode in the migration tool first.
PostgreSQL does not have a configuration option to always treat identifiers as quoted or to use case-insensitive identifier comparisons.
This is far from the only incompatibility you will encounter, so be prepared to change queries and application code. In some cases you might even need one query for MySQL and another for PostgreSQL if you plan to continue to support MySQL.
If you weren't using sql_mode = ANSI and using STRICT mode in MySQL you'll have a lot more trouble with porting than if you were using those options, since both options bring MySQL closer to SQL standard behaviour.
Forgot to make a backup. Now I have harddrive with databases and new system with empty postgres. Can I somehow restore databases? by simple copy of files etc?
If you have the full data directory of your old postgresql system (and if it was the same version, or differing only in a revision number) you can just try to put it in place of your data directory in your new postgresql installation. (Of course, stop postgres server before doing this).
It's basically the same procedure used when upgrading postgresql, when there is no need to do backup-restore.
Edit: As pointed out in the comments, I assume not only same (or almost same) version, but same architecture (32 - 64 bits , Linux - Windows, etc)
In addition to the leonbloy's answer, you could try pg_migrator, especially if you need to upgrade from 8.3 to 8.4 (and 9.0 eventually).
In your case you have the files, but if you haven't, Maybe, only maybe, you can do something with the logs of the database, you can try to see the log of the statements in the database normally in /var/log/postgresql/postgresql.log, if it is there or close to it, and if log_statements = 'mod' or 'all' is set up before, you can recovery some of your data.
Table by table, by searching by insert into in this tables in all or recent history of database. You can cut text with some Unix tools to get only the statements and put a ";" at the end of each statement, and another important queries like delete, etc.
But you must to do it table by table, and data must be there, and database don't runned up too much time without backups.
In certain cases you just need the last operation or something like this to save the day.
This, however, its just for Apolo 13 disasters moment and never can replace a good backup.