I am trying to create a table that was dropped previously.
But when I do the CREATE TABLE A ..
. I am getting below error:
Relation ‘A’ already exists.
I verified doing SELECT * FROM A
, but then I got another error:
Relation ‘A’ does not exists.
I already tried to find it in dS+
listing all relations, and it is not there.
To complicate this, I have tested this by creating this table in another database and I got the same error. I am thinking that could be an error when this table was dropped. Any ideas?
Here is the code: I’m using a generated code from Power SQL. I have the same error without using the sequence. It just works when I change the name and in this case I can not do that.
CREATE SEQUENCE csd_relationship_csd_relationship_id_seq;
CREATE TABLE csd_relationship (
csd_relationship_id INTEGER NOT NULL DEFAULT nextval('csd_relationship_csd_relationship_id_seq'::regclass),
type_id INTEGER NOT NULL,
object_id INTEGER NOT NULL,
CONSTRAINT csd_relationship PRIMARY KEY (csd_relationship_id)
);
asked Jan 9, 2012 at 17:55
2
I finally discover the error. The problem is that the primary key constraint name is equal the table name. I don know how postgres represents constraints, but I think the error «Relation already exists» was being triggered during the creation of the primary key constraint because the table was already declared. But because of this error, the table wasnt created at the end.
answered Jan 12, 2012 at 12:57
nsbmnsbm
5,6266 gold badges29 silver badges45 bronze badges
5
There should be no single quotes here 'A'
. Single quotes are for string literals: 'some value'
.
Either use double quotes to preserve the upper case spelling of «A»:
CREATE TABLE "A" ...
Or don’t use quotes at all:
CREATE TABLE A ...
which is identical to
CREATE TABLE a ...
because all unquoted identifiers are folded to lower case automatically in PostgreSQL.
You can avoid problems with the index name completely by using simpler syntax:
CREATE TABLE csd_relationship (
csd_relationship_id serial PRIMARY KEY,
type_id integer NOT NULL,
object_id integer NOT NULL
);
Does the same as your original query, only it avoids naming conflicts by picking the next free identifier automatically. More about the serial
type in the manual.
answered Jan 9, 2012 at 18:42
Erwin BrandstetterErwin Brandstetter
579k139 gold badges1035 silver badges1189 bronze badges
1
You cannot create a table with a name that is identical to an existing table or view in the cluster. To modify an existing table, use ALTER TABLE
(link), or to drop all data currently in the table and create an empty table with the desired schema, issue DROP TABLE
before CREATE TABLE
.
It could be that the sequence you are creating is the culprit. In PostgreSQL, sequences are implemented as a table with a particular set of columns. If you already have the sequence defined, you should probably skip creating it. Unfortunately, there’s no equivalent in CREATE SEQUENCE
to the IF NOT EXISTS
construct available in CREATE TABLE
. By the looks of it, you might be creating your schema unconditionally, anyways, so it’s reasonable to use
DROP TABLE IF EXISTS csd_relationship;
DROP SEQUENCE IF EXISTS csd_relationship_csd_relationship_id_seq;
before the rest of your schema update; In case it isn’t obvious, This will delete all of the data in the csd_relationship
table, if there is any
jawr
8071 gold badge7 silver badges14 bronze badges
answered Jan 10, 2012 at 17:25
2
Another reason why you might get errors like «relation already exists» is if the DROP
command did not execute correctly.
One reason this can happen is if there are other sessions connected to the database which you need to close first.
answered Sep 21, 2018 at 11:58
isedwardsisedwards
2,42920 silver badges29 bronze badges
In my case, I had a sequence with the same name.
answered Aug 25, 2016 at 15:06
In my case, it wasn’t until I PAUSEd the batch file and scrolled up a bit, that wasn’t the only error I had gotten. My DROP
command had become DROP
and so the table wasn’t dropping in the first place (thus the relation did indeed still exist). The 
I’ve learned is called a Byte Order Mark (BOM). Opening this in Notepad++, re-save the SQL file with Encoding set to UTM-8 without BOM and it runs fine.
Mogsdad
44.1k21 gold badges151 silver badges272 bronze badges
answered Jan 11, 2016 at 18:25
0
You may be running the CREATE TABLE
after already running it. So you may be creating a table for a second time, while the first attempt already created it.
answered May 14, 2021 at 19:03
ScottyBladesScottyBlades
11.1k5 gold badges71 silver badges76 bronze badges
In my case I was migrating from 9.5 to 9.6.
So to restore a database, I was doing :
sudo -u postgres psql -d databse -f dump.sql
Of course it was executing on the old postgreSQL database where there are datas! If your new instance is on port 5433, the correct way is :
sudo -u postgres psql -d databse -f dump.sql -p 5433
answered Oct 5, 2016 at 10:30
Sometimes this kind of error happens when you create tables with different database users and try to SELECT
with a different user.
You can grant all privileges using below query.
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA schema_name TO username;
And also you can grant access for DML statements
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA schema_name TO username;
answered Nov 10, 2020 at 2:19
1
-
The problem is that the primary key constraint name is equal the table name.
-
I don’t know how postgres represents constraints, but I think the error “Relation
already exists” was being triggered during the creation of the primary key
constraint because the table was already declared. But because of this error,
the table wasnt created at the end. -
give different name to constrain
Note- go to SQL tab and check table name and constrain
Enjoy
answered Oct 20, 2022 at 15:54
mariammm 1 / 1 / 0 Регистрация: 24.09.2019 Сообщений: 173 |
||||
1 |
||||
Ошибка при попытке создать таблицу15.10.2020, 17:50. Показов 4423. Ответов 2 Метки нет (Все метки)
Пишу код и нажимаю на кнопку для создания, в первый раз всё ок, в следующие разы появляется ошибка ERROR: ОШИБКА: отношение «cabins» уже существует SQL state: 42P07
Миниатюры
__________________
0 |
1187 / 917 / 367 Регистрация: 02.09.2012 Сообщений: 2,796 |
|
15.10.2020, 23:22 |
2 |
Так и что тут удивительного.
1 |
remarkes 309 / 232 / 15 Регистрация: 01.07.2011 Сообщений: 812 Записей в блоге: 1 |
||||||||
17.10.2020, 18:40 |
3 |
|||||||
Потом заново создаёте таблицу вашими командами.
1 |
Ошибка:
отношение "users" уже существует [Failed SQL: (0) CREATE TABLE public.users
. Проблема в том, что я и так знаю, что существует, но у меня в application.properties
стоит spring.jpa.hibernate.ddl-auto=validate
Тогда почему эта ошибка всё равно появляется? Может, у меня sql-запрос неверный? Использую posgresql
.
CREATE TABLE public.users
(
id bigint NOT NULL GENERATED BY DEFAULT AS IDENTITY ( INCREMENT 1 START 1 MINVALUE 1 MAXVALUE 9223372036854775807 CACHE 1 ),
email character varying(255) COLLATE pg_catalog."default" NOT NULL,
first_name character varying(255) COLLATE pg_catalog."default" NOT NULL,
last_name character varying(255) COLLATE pg_catalog."default" NOT NULL,
password character varying(255) COLLATE pg_catalog."default" NOT NULL,
role character varying(255) COLLATE pg_catalog."default",
status character varying(255) COLLATE pg_catalog."default",
CONSTRAINT users_pkey PRIMARY KEY (id),
CONSTRAINT uk_6dotkott2kjsp8vw4d0m25fb7 UNIQUE (email)
)
TABLESPACE pg_default;
ALTER TABLE public.users
OWNER to root;
Ссылка на код, если не пригодится, то удалю.
2020-10-03 18:10:31.010 ERROR 11936 --- [ main] liquibase.changelog.ChangeSet : Change Set classpath:db/changelog/v-1.0/01-changeset-users-table.xml::2::vladislav_gil failed. Error: ОШИБКА: отношение "users" уже существует [Failed SQL: (0) CREATE TABLE public.users
(
id bigint NOT NULL GENERATED BY DEFAULT AS IDENTITY ( INCREMENT 1 START 1 MINVALUE 1 MAXVALUE 9223372036854775807 CACHE 1 ),
email character varying(255) COLLATE pg_catalog."default" NOT NULL,
first_name character varying(255) COLLATE pg_catalog."default" NOT NULL,
last_name character varying(255) COLLATE pg_catalog."default" NOT NULL,
password character varying(255) COLLATE pg_catalog."default" NOT NULL,
role character varying(255) COLLATE pg_catalog."default",
status character varying(255) COLLATE pg_catalog."default",
CONSTRAINT users_pkey PRIMARY KEY (id),
CONSTRAINT uk_6dotkott2kjsp8vw4d0m25fb7 UNIQUE (email)
)
TABLESPACE pg_default;
ALTER TABLE public.users
OWNER to root]
2020-10-03 18:10:31.012 INFO 11936 --- [ main] l.lockservice.StandardLockService : Successfully released change log lock
2020-10-03 18:10:31.014 WARN 11936 --- [ main] ConfigServletWebServerApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'liquibase' defined in class path resource [org/springframework/boot/autoconfigure/liquibase/LiquibaseAutoConfiguration$LiquibaseConfiguration.class]: Invocation of init method failed; nested exception is liquibase.exception.MigrationFailedException: Migration failed for change set classpath:db/changelog/v-1.0/01-changeset-users-table.xml::2::vladislav_gil:
Reason: liquibase.exception.DatabaseException: ОШИБКА: отношение "users" уже существует [Failed SQL: (0) CREATE TABLE public.users
(
id bigint NOT NULL GENERATED BY DEFAULT AS IDENTITY ( INCREMENT 1 START 1 MINVALUE 1 MAXVALUE 9223372036854775807 CACHE 1 ),
email character varying(255) COLLATE pg_catalog."default" NOT NULL,
first_name character varying(255) COLLATE pg_catalog."default" NOT NULL,
last_name character varying(255) COLLATE pg_catalog."default" NOT NULL,
password character varying(255) COLLATE pg_catalog."default" NOT NULL,
role character varying(255) COLLATE pg_catalog."default",
status character varying(255) COLLATE pg_catalog."default",
CONSTRAINT users_pkey PRIMARY KEY (id),
CONSTRAINT uk_6dotkott2kjsp8vw4d0m25fb7 UNIQUE (email)
)
TABLESPACE pg_default;
ALTER TABLE public.users
OWNER to root]
2020-10-03 18:10:31.014 INFO 11936 --- [ main] com.zaxxer.hikari.HikariDataSource : HikariPool-1 - Shutdown initiated...
2020-10-03 18:10:31.026 INFO 11936 --- [ main] com.zaxxer.hikari.HikariDataSource : HikariPool-1 - Shutdown completed.
2020-10-03 18:10:31.029 INFO 11936 --- [ main] o.apache.catalina.core.StandardService : Stopping service [Tomcat]
2020-10-03 18:10:31.038 INFO 11936 --- [ main] ConditionEvaluationReportLoggingListener :
Error starting ApplicationContext. To display the conditions report re-run your application with 'debug' enabled.
2020-10-03 18:10:31.044 ERROR 11936 --- [ main] o.s.boot.SpringApplication : Application run failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'liquibase' defined in class path resource [org/springframework/boot/autoconfigure/liquibase/LiquibaseAutoConfiguration$LiquibaseConfiguration.class]: Invocation of init method failed; nested exception is liquibase.exception.MigrationFailedException: Migration failed for change set classpath:db/changelog/v-1.0/01-changeset-users-table.xml::2::vladislav_gil:
Reason: liquibase.exception.DatabaseException: ОШИБКА: отношение "users" уже существует [Failed SQL: (0) CREATE TABLE public.users
(
id bigint NOT NULL GENERATED BY DEFAULT AS IDENTITY ( INCREMENT 1 START 1 MINVALUE 1 MAXVALUE 9223372036854775807 CACHE 1 ),
email character varying(255) COLLATE pg_catalog."default" NOT NULL,
first_name character varying(255) COLLATE pg_catalog."default" NOT NULL,
last_name character varying(255) COLLATE pg_catalog."default" NOT NULL,
password character varying(255) COLLATE pg_catalog."default" NOT NULL,
role character varying(255) COLLATE pg_catalog."default",
status character varying(255) COLLATE pg_catalog."default",
CONSTRAINT users_pkey PRIMARY KEY (id),
CONSTRAINT uk_6dotkott2kjsp8vw4d0m25fb7 UNIQUE (email)
)
TABLESPACE pg_default;
ALTER TABLE public.users
OWNER to root]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1803) ~[spring-beans-5.2.0.RELEASE.jar:5.2.0.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:595) ~[spring-beans-5.2.0.RELEASE.jar:5.2.0.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:517) ~[spring-beans-5.2.0.RELEASE.jar:5.2.0.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:323) ~[spring-beans-5.2.0.RELEASE.jar:5.2.0.RELEASE]
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) ~[spring-beans-5.2.0.RELEASE.jar:5.2.0.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:321) ~[spring-beans-5.2.0.RELEASE.jar:5.2.0.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202) ~[spring-beans-5.2.0.RELEASE.jar:5.2.0.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:310) ~[spring-beans-5.2.0.RELEASE.jar:5.2.0.RELEASE]
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202) ~[spring-beans-5.2.0.RELEASE.jar:5.2.0.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1108) ~[spring-context-5.2.0.RELEASE.jar:5.2.0.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:868) ~[spring-context-5.2.0.RELEASE.jar:5.2.0.RELEASE]
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:550) ~[spring-context-5.2.0.RELEASE.jar:5.2.0.RELEASE]
... 31 common frames omitted
Я пытаюсь создать таблицу, которая была удалена ранее.
Но когда я делаю CREATE TABLE A ..
. Я получаю сообщение об ошибке ниже:
Отношение «А» уже существует.
Я подтвердил выполнение SELECT * FROM A
, но затем получил еще одну ошибку:
Отношения «А» не существует.
Я уже пытался найти его в списке всех отношений dS+
, но его там нет.
Чтобы усложнить ситуацию, я проверил это, создав эту таблицу в другой базе данных, и получил ту же ошибку. Я думаю, что это могло быть ошибкой, когда эта таблица была удалена. Любые идеи?
Вот код: я использую сгенерированный код из Power SQL. У меня такая же ошибка без использования последовательности. Это просто работает, когда я меняю имя, и в этом случае я не могу этого сделать.
CREATE SEQUENCE csd_relationship_csd_relationship_id_seq;
CREATE TABLE csd_relationship (
csd_relationship_id INTEGER NOT NULL DEFAULT nextval('csd_relationship_csd_relationship_id_seq'::regclass),
type_id INTEGER NOT NULL,
object_id INTEGER NOT NULL,
CONSTRAINT csd_relationship PRIMARY KEY (csd_relationship_id)
);
Я наконец обнаружил ошибку. Проблема в том, что имя ограничения первичного ключа совпадает с именем таблицы. Я не знаю, как postgres представляет ограничения, но я думаю, что ошибка «Связь уже существует» была вызвана во время создания ограничения первичного ключа, потому что таблица уже была объявлена. Но из-за этой ошибки таблица не была создана в конце.
68
nsbm
12 Янв 2012 в 16:57
Другая причина, по которой вы можете получить такие ошибки, как «отношение уже существует», — это неправильное выполнение команды DROP
.
Одна из причин, по которой это может произойти, заключается в том, что к базе данных подключены другие сеансы, которые необходимо закрыть в первую очередь.
4
isedwards
21 Сен 2018 в 14:58
В моем случае это было только после того, как я приостановил пакетный файл и немного прокрутил его вверх, это была не единственная ошибка, которую я получил. Моя команда DROP
превратилась в DROP
, поэтому таблица не удалялась в первую очередь (таким образом, связь действительно все еще существовала). Я узнал, что 
называется меткой порядка байтов (BOM). Открыв это в Notepad ++, повторно сохраните файл SQL с кодировкой UTM-8 без спецификации, и он будет работать нормально.
2
Mogsdad
11 Янв 2016 в 22:03
В моем случае у меня была последовательность с таким же названием.
4
Dave Van den Eynde
25 Авг 2016 в 18:06
Иногда такая ошибка возникает, когда вы создаете таблицы с разными пользователями базы данных и пытаетесь SELECT
с другим пользователем. Вы можете предоставить все привилегии, используя запрос ниже.
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA schema_name TO username;
А также вы можете предоставить доступ для операторов DML
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA schema_name TO username;
1
Akila K Gunawardhana
10 Ноя 2020 в 05:19
В моем случае я переходил с 9.5 на 9.6. Итак, чтобы восстановить базу данных, я делал:
sudo -u postgres psql -d databse -f dump.sql
Конечно, он выполнялся в старой базе данных postgreSQL, где есть данные! Если ваш новый экземпляр находится на порту 5433, правильный способ:
sudo -u postgres psql -d databse -f dump.sql -p 5433
0
Nicolas Boisteault
5 Окт 2016 в 13:30
Возможно, вы запускаете CREATE TABLE
после того, как уже запустили его. Таким образом, вы можете создать таблицу во второй раз, а первая попытка уже создала ее.
1
ScottyBlades
14 Май 2021 в 22:03
Содержание
- Debugging “relation does not exist” error in postgres
- Нельзя просто использовать имя таблицы PostgreSQL («отношение не существует»)
- 7 ответов:
- Нельзя просто использовать имя таблицы PostgreSQL («отношения не существует»)
- org.postgresql.util.PSQLException: ОШИБКА: отношение «app_user» не существует
- 3 ответа
- Java SQL «ОШИБКА: отношение» Имя_таблицы «не существует»
- 4 ответы
Debugging “relation does not exist” error in postgres
So, i was getting this nasty error even when the table clearly existed in t11 database.
Even after lot of googling, debugging and trying Stackoverflow solutions, there was no resolution. Then i got a hunch, that i should check what database and schema were actually being used when done programmatically (even though dbname was clearly provided in connection string).
If you use database t11 by running c t11 and then run:
select * from information_schema.tables where table_schema NOT IN (‘pg_catalog’, ‘information_schema’)
It will tell you that userinfo5 does exist in t11 database. But what happens when we try to access it programmatically?
So, i ran above query in a golang function, the function which was earlier running query select * from userinfo5 where >
Output showed that database name which was actually being used was postgres and not t11 Why?
Because, my postgres user was configured to not use password. But my connection string had password= This was somehow confusing the DB driver and postgres database was being used and not t11 .
remove password= from connection string so that it looks like: “host=localhost port=5432 user=postgres dbname=t11 sslmode=disable”
- Alter user postgres so that it uses password: alter user postgres with password ‘pwd123’;
- Change connection string: “host=localhost port=5432 user=postgres password=pwd123 dbname=t11 sslmode=disable”
Источник
Нельзя просто использовать имя таблицы PostgreSQL («отношение не существует»)
Я пытаюсь запустить следующий PHP-скрипт для выполнения простого запроса к базе данных:
это приводит к следующей ошибке:
ошибка запроса: ошибка: отношение «sf_bands» не существует
во всех примерах я могу найти, где кто-то получает ошибку о том, что связь не существует, это потому, что они используют прописные буквы в имени своей таблицы. Мое имя таблицы не имеет прописных букв. Есть ли способ запросить мою таблицу без включения имени базы данных, т. е. showfinder.sf_bands ?
7 ответов:
из того, что я прочитал, эта ошибка означает, что вы не ссылаетесь на имя таблицы правильно. Одна из распространенных причин заключается в том, что таблица определяется со смешанным написанием, и вы пытаетесь запросить ее со всеми строчными буквами.
другими словами, следующее терпит неудачу:
используйте двойные кавычки для разграничения идентификаторов, чтобы вы могли использовать конкретное смешанное написание, как определено в таблице.
Re ваш комментарий, вы можете добавить схему в «search_path», чтобы при ссылке на имя таблицы без уточнения ее схемы запрос соответствовал этому имени таблицы, проверяя каждую схему по порядку. Так же, как PATH в оболочке или include_path в PHP и др. Вы можете проверить свой текущий путь поиска схема:
вы можете изменить путь поиска схемы:
у меня были проблемы с этим и это история (печальная, но правдивая) :
если ваше имя таблицы все строчные, как: счета вы можете использовать: select * from AcCounTs и он будет работать нормально
если ваше имя таблицы все строчные, как: accounts Следующее не удастся: select * from «AcCounTs»
если ваше имя таблицы смешанный случай как: Accounts Следующее не удастся: select * from accounts
если ваше имя таблицы это смешанный случай как : Accounts Следующее будет работать нормально: select * from «Accounts»
Я не люблю вспоминать бесполезные вещи, как это, но надо 😉
запрос процесса Postgres отличается от других RDMS. Поместите имя схемы в двойную кавычку перед именем таблицы, например, «SCHEMA_NAME».»SF_Bands»
поместите параметр dbname в строку подключения. Это работает для меня, в то время как все остальное не удалось.
также, когда делаешь выбор, указать your_schema . your_table такой:
У меня была аналогичная проблема на OSX, но я пытался играть с двойными и одинарными кавычками. Для вашего случая, вы могли бы попробовать что-то вроде этого
для меня проблема заключалась в том, что я использовал запрос к этой конкретной таблице во время инициализации Django. Конечно, это вызовет ошибку, потому что эти таблицы не существовали. В моем случае это было get_or_create метод в пределах a admin.py файл, который выполнялся всякий раз, когда программное обеспечение выполняло какую-либо операцию (в данном случае миграцию). Надеюсь, это кому-то поможет.
я копал эту проблему больше, и узнал о том, как установить этот «search_path» по defoult для нового пользователя в текущей базе данных.
открыть Свойства базы данных, затем открыть лист » переменные» и просто добавьте эту переменную для вашего пользователя с фактическим значением.
Так что теперь ваш пользователь получит это schema_name по умолчанию, и вы можете использовать tableName без schemaName.
Источник
Нельзя просто использовать имя таблицы PostgreSQL («отношения не существует»)
Я пытаюсь запустить следующий скрипт PHP, чтобы выполнить простой запрос к базе данных:
Это приводит к следующей ошибке:
Ошибка запроса: ERROR: отношения «sf_bands» не существует
Во всех примерах я могу найти, где кто-то получает ошибку, указывающую, что отношения не существует, потому что они используют заглавные буквы в имени своей таблицы. В моем имени таблицы нет заглавных букв. Есть ли способ запросить мою таблицу без включения имени базы данных, то есть showfinder.sf_bands ?
Из того, что я прочитал, эта ошибка означает, что вы неправильно ссылаетесь на имя таблицы. Одной из распространенных причин является то, что таблица определена с орфографией с смешанным регистром, и вы пытаетесь запросить ее со всеми строчными буквами.
Другими словами, следующее не выполняется:
Используйте двойные кавычки, чтобы разграничить идентификаторы, чтобы вы могли использовать конкретную орфографию с смешанным регистром, поскольку таблица определена.
Повторите свой комментарий, вы можете добавить схему в «путь поиска», чтобы при ссылке на имя таблицы без квалификации ее схемы запрос соответствовал этому имени таблицы, проверив каждую схему в порядке. Точно так же, как PATH в оболочке или include_path в PHP и т. Д. Вы можете проверить свой текущий путь поиска схемы:
Вы можете изменить путь поиска схемы:
У меня были проблемы с этим, и это история (грустная, но правда):
Если имя вашей таблицы имеет нижний регистр, например: учетные записи, которые вы можете использовать: select * from AcCounTs и он будет работать нормально
Если ваше имя таблицы имеет все нижеследующее значение, например: accounts Следующие select * from «AcCounTs» не будут выполнены: select * from «AcCounTs»
Если ваше имя таблицы смешанно, например: Accounts : Accounts : select * from accounts
Если ваше имя таблицы смешанно, например: Accounts Следующие будут работать нормально: select * from «Accounts»
Я не люблю вспоминать бесполезные вещи, как это, но вы должны;)
Запрос процесса Postgres отличается от других RDMS. Поместите имя схемы в двойную кавычку перед именем вашей таблицы, например «SCHEMA_NAME». «SF_Bands»
Поместите параметр dbname в строку подключения. Это работает для меня, пока все остальное не удалось.
Также, когда вы делаете выбор, укажите your_schema . your_table :
У меня была аналогичная проблема с OSX, но я старался играть с двойными и одинарными кавычками. В вашем случае вы можете попробовать что-то вроде этого
Источник
org.postgresql.util.PSQLException: ОШИБКА: отношение «app_user» не существует
У меня есть приложение, в котором я использую spring boot и postgres. Я получаю эту ошибку, когда пытаюсь создать пользователя.
Когда я запускаю этот запрос в своей базе данных, я получаю ту же ошибку:
Но если я изменил это на:
Как мне настроить это приложение для загрузки spring?
зависимости в pom.xml:
Я вызываю это действие из формы:
и это мой контроллер:
Валидатор, который исправляет ошибку:
И репозиторий является интерфейсом CrudRepository и не имеет реализации:
И отлаживая валидатор, я мог бы получить этот стек:
Спасибо за помощь!
3 ответа
PostgreSQL соответствует стандарту SQL и в этом случае означает, что идентификаторы (имена таблиц, имена столбцов и т.д.) принудительно строятся в нижнем регистре, за исключением случаев, когда они цитируются. Поэтому, когда вы создаете таблицу следующим образом:
вы фактически получаете таблицу app_user . Вы, очевидно, сделали:
а затем вы получите таблицу «APP_USER» .
В Spring вы указываете правильную строку для имени таблицы заглавными буквами, но ее объединяют в запрос на сервер PostgreSQL без кавычек. Вы можете проверить это, прочитав файлы журнала PostgreSQL: он должен показать запрос, сгенерированный Spring, за которым следует ошибка в верхней части вашего сообщения.
Поскольку у вас очень мало контроля над тем, как Spring строит запросы от сущностей, вам лучше использовать идентификаторы нижнего регистра стандарта SQL.
Источник
Java SQL «ОШИБКА: отношение» Имя_таблицы «не существует»
Я пытаюсь подключить netbeans к моей базе данных postgresql. Кажется, что соединение сработало, поскольку я не получаю никаких ошибок или исключений при простом подключении, такие методы, как getCatalog (), также возвращают правильные ответы.
Но когда я пытаюсь запустить простой оператор SQL, я получаю сообщение об ошибке «ОШИБКА: отношение« TABLE_NAME »не существует», где TABLE_NAME — это любая из моих таблиц, которые ДЕЙСТВИТЕЛЬНО существуют в базе данных. Вот мой код:
Я думал, что netbeans может не находить таблицы, потому что он не ищет схему по умолчанию (общедоступную), есть ли способ установить схему в java?
РЕДАКТИРОВАТЬ: мой код подключения. Имя базы данных — Cinemax, когда я опускаю код оператора, я не получаю ошибок.
Разве нельзя так переписать sql? SELECT * FROM .clients — CoolBeans
Вы не показываете, как вы подключаетесь к серверу базы данных. Я подозреваю, что @CoolBeans верен выше или очень близко. Ваша таблица находится в другой схеме (что будет исправлено выше) или в другой базе данных, чем та, которую вы указали при подключении. — Brian Roach
Мне это нравится . не могли бы вы показать нам НАСТОЯЩУЮ ошибку? Я не думаю, что база данных говорит «отношение TABLE_NAME . », когда вы выполняете «select * from clients». — Szymon Lipiński
Я пробовал это, но получаю ту же ошибку: «ОШИБКА: отношение« public.clients »не существует» (то же самое для любой другой из моих таблиц). public — моя единственная схема, так что это также схема по умолчанию. Спасибо за помощь. — Matt
Установите для log_min_duration_statement значение 0 в postgresql.conf, перезапустите базу данных, запустите приложение и проверьте в журналах postgresql, какой реальный запрос отправляется в базу данных. И еще кое-что . вы на 100% уверены, что у вас есть стол? Можете ли вы подключиться к этой базе данных с помощью psql / pgadmin и выполнить там запрос? — Szymon Lipiński
4 ответы
Я подозреваю, что вы создали таблицу, используя двойные кавычки, например, «Clients» или какая-либо другая комбинация символов верхнего / нижнего регистра, поэтому имя таблицы теперь чувствительно к регистру.
Что означает заявление
Если возвращаемое имя таблицы не в нижнем регистре, вы должны использовать двойные кавычки при обращении к нему, что-то вроде этого:
ответ дан 24 апр.
Я пытаюсь использовать sequelize ORM, и в своем запросе на создание он использует кавычки в table_name. Спасибо за ответ. — Kiddo
Источник
Я пытаюсь создать таблицу, которая была ранее удалена.
Но когда я делаю CREATE TABLE A ..
. Я получаю ниже ошибки:
Отношение «A» уже существует.
Я проверил выполнение SELECT * FROM A
, но потом я получил еще одну ошибку:
Отношение «A» не существует.
Я уже пытался найти его в dS+
, в котором перечислены все отношения, и его там нет.
Чтобы усложнить это, я проверил это, создав эту таблицу в другой базе данных, и я получил ту же ошибку. Я думаю, что это может быть ошибка, когда эта таблица была удалена. Любые идеи?
Вот код: я использую сгенерированный код из Power SQL. У меня такая же ошибка без использования последовательности. Он просто работает, когда я меняю имя, и в этом случае я не могу этого сделать.
CREATE SEQUENCE csd_relationship_csd_relationship_id_seq;
CREATE TABLE csd_relationship (
csd_relationship_id INTEGER NOT NULL DEFAULT nextval('csd_relationship_csd_relationship_id_seq'::regclass),
type_id INTEGER NOT NULL,
object_id INTEGER NOT NULL,
CONSTRAINT csd_relationship PRIMARY KEY (csd_relationship_id)
);
Ответ 1
Наконец-то я обнаружил ошибку. Проблема в том, что имя ограничения первичного ключа равно имени таблицы. Я не знаю, как postgres представляет ограничения, но я думаю, что ошибка «Отношение уже существует» запускалась во время создания ограничения первичного ключа, потому что таблица уже была объявлена. Но из-за этой ошибки таблица не была создана в конце.
Ответ 2
Здесь не должно быть никаких кавычек 'A'
. Одиночные кавычки для строковых литералов: 'some value'
.
Либо используйте двойные кавычки, чтобы сохранить правописание в верхнем регистре «A»:
CREATE TABLE "A" ...
Или вообще не использовать кавычки:
CREATE TABLE A ...
который идентичен
CREATE TABLE A ...
потому что все неуказанные идентификаторы автоматически складываются в нижний регистр в PostgreSQL.
Вы можете полностью избежать проблем с именем индекса, используя более простой синтаксис:
CREATE TABLE csd_relationship (
csd_relationship_id serial PRIMARY KEY,
type_id integer NOT NULL,
object_id integer NOT NULL
);
Выполняет то же самое, что и исходный запрос, только это позволяет избежать конфликтов имен автоматически. Он автоматически выбирает следующий свободный идентификатор. Подробнее о серийном типе в руководстве.
Ответ 3
Вы не можете создать таблицу с именем, которое идентично существующей таблице или представлению в кластере. Чтобы изменить существующую таблицу, используйте ALTER TABLE
(link) или удалите все данные, находящиеся в настоящее время в таблице, и создайте пустую таблицу с нужным schema, вопрос DROP TABLE
до CREATE TABLE
.
Возможно, что создаваемая вами последовательность является виновником. В PostgreSQL последовательности реализуются как таблица с определенным набором столбцов. Если у вас уже определенная последовательность, вам, вероятно, следует пропустить ее. К сожалению, нет эквивалента в CREATE SEQUENCE
для конструкции IF NOT EXISTS
, доступной в CREATE TABLE
. По внешнему виду, вы можете создать свою схему безоговорочно, так или иначе, поэтому разумно использовать
DROP TABLE IF EXISTS csd_relationship;
DROP SEQUENCE IF EXISTS csd_relationship_csd_relationship_id_seq;
до остальной части вашего обновления схемы; Если это не очевидно, Это приведет к удалению всех данных в таблице csd_relationship
, если есть
Ответ 4
В моем случае это было только до тех пор, пока я не запустил пакетный файл и немного прокрутился, это была не единственная ошибка, которую я получил. Моя команда DROP
стала DROP
, и поэтому таблица не упала в первую очередь (таким образом, отношение действительно существовало). 
Я узнал, что он называется знаком байтового байта (BOM). Открыв это в Notepad ++, заново сохраните файл SQL с кодировкой, установленной в UTM-8 без спецификации, и она отлично работает.
Ответ 5
В моем случае у меня была последовательность с тем же именем.
Ответ 6
В моем случае я переходил с 9.5 до 9.6.
Поэтому для восстановления базы данных я делал:
sudo -u postgres psql -d databse -f dump.sql
Конечно, он выполнялся в старой базе данных postgreSQL, где есть данные! Если ваш новый экземпляр находится на порту 5433, правильный способ:
sudo -u postgres psql -d databse -f dump.sql -p 5433
Ответ 7
Это связано с тем, что таблица A уже существует, когда вы пытаетесь ее создать.
откройте таблицу A и убедитесь, что она не существует.