I have a view and want to make one attribute a primary key.
CREATE VIEW filedata_view
AS SELECT num PRIMARY KEY, id, ST_TRANSFORM(the_geom,900913) AS the_geom
FROM filedata
But get a error
ERROR: syntax error at or near "PRIMARY"
LINE 2: AS SELECT num PRIMARY KEY, id, ST_TRANSFORM(the_geom,900913)...
How to do this?
Views in Postgresql can't have primary keys.
you are basically on wrong way creating constraint on a View, constraints should be created on tables, but some DBMSes do support adding constraints on Views like oracle with this syntax:
ALTER VIEW VIEW_NAME ADD PRIMARY KEY PK_VIEW_NAME DISABLE NOVALIDATE;
Oracle Doc For Constraints
You can specify only unique, primary key, and foreign key constraints on views, and they are supported only in DISABLE NOVALIDATE mode.
so they only support it for compatibility, if you want to have a primary key to stop insertion of duplicate data in column num in filedata table, you should do it by altering the filedata table and add a primary key on it or by creating your table with primary key on column num from the start.
Postgresql doesn't support constraints on views. Other DBMSes (eg Oracle) do support this but Postgresql doesn't.
Related
I'm trying to truncate a set of tables, but it keeps complaining about a foreign key.
but that foreign key is set to on delete Set null
to reproduce:
create table test_players (id SERIAL PRIMARY KEY, name VARCHAR(255));
create table test_items (id SERIAL PRIMARY KEY, name VARCHAR(255), player_id INTEGER FOREIGN KEY (player_id) REFERENCES test_players(id) ON DELETE SET NULL);
now if you truncate the test_players it will complain:
ERROR: cannot truncate a table referenced in a foreign key constraint
DETAIL: Table "test_items" references "test_players".
HINT: Truncate table "test_items" at the same time, or use TRUNCATE ... CASCADE.
SQL state: 0A000
what must I do to make me be able to delete test_players without deleting the test_items?
You cannot do what you are attempting. You will have to do this in 3 steps.
Update test_items and for each player_id. Well technically you don't need this, but if you don't give yourself data integrity issues.
Drop the test_items to test_players FK.
Then truncate test_players
The reason is that truncate basically just zaps the table, it does NOT process individual rows. Therefore it would not process the FK set null, it throws the error you got instead. In fact even if the child table is empty, or for that matter even if the parent is empty. See fiddle here. The fiddle also contains a function to do it, and a test for it.
The of course you could just Delete from test_players and let the triggers take care of updating test_items. Takes longer, esp if larger table, but you keep your FK. Of course there's
Recreate your FK.
TL;DR
I am seeking clarity on this: does a FOREIGN KEY require a UNIQUE CONSTRAINT on the other side, specifically, in Postgres and, generally, in relational database systems?
Perhaps, I can test this, but I'll ask, if the UNIQUE CONSTRAINT is required by the FOREIGN KEY what would happen if I don't create it? Will the Database create one or will it throw an error?
How I got there
I had earlier on created a table with a column username on which I imposed a unique constraint. I then created another table with a column bearer_name having a FOREIGN KEY referencing the previous table's column username; the one which had a UNIQUE CONSTRAINT.
Now, I want to drop the UNIQUE CONSTRAINT on the username column from the database because I have later on created a UNIQUE INDEX on the same column and intuitively I feel that they serve the same purpose, or don't they? But the database is complaining that the UNIQUE INDEX has some dependent objects and so it can't be dropped unless I provide CASCADE as an option in order to drop even the dependent object. It's identifying the FOREIGN KEY on bearer_name column in the second table as the dependent object.
And is it possible for the FOREIGN KEY to be a point to the UNIQUE INDEX instead of the UNIQUE CONSTRAINT?
I am seeking clarity on this: does a FOREIGN KEY require a UNIQUE CONSTRAINT on the other side
No it does not require only UNIQUE CONSTRAINT. It could be PRIMARY KEY or UNIQUE INDEX.
Perhaps, I can test this, but I'll ask, if the UNIQUE CONSTRAINT is required by the FOREIGN KEY what would happen if I don't create it? Will the Database create one or will it throw an error?
CREATE TABLE tab_a(a_id INT, b_id INT);
CREATE TABLE tab_b(b_id INT);
ALTER TABLE tab_a ADD CONSTRAINT fk_tab_a_tab_b FOREIGN KEY (b_id)
REFERENCES tab_b(b_id);
ERROR: there is no unique constraint matching given keys
for referenced table "tab_b"
DBFiddle Demo
And is it possible for the FOREIGN KEY to be a point to the UNIQUE INDEX instead of the UNIQUE CONSTRAINT?
Yes, it is possible.
CREATE UNIQUE INDEX tab_b_i ON tab_b(b_id);
DBFiddle Demo2
I have a dataframe with an index that I want to store in a postgresql database. For this I use df.to_sql(table_name,engine,if_exists='replace', index=True,chunksize=10000)
The index column from the pandas dataframe is copied to the database but is not set as primary key.
There are two solutions that require an additional step:
specify a schema df.to_sql(schema=) docs
Set the primary key after the table is ingested. query:
ALTER TABLE table_name ADD PRIMARY KEY (id_column_name)
Is there a way to set the primary key without specifying the schema or altering the table?
After calling to_sql:
import sqlalchemy
engine = create_engine()
engine.execute('ALTER TABLE schema.table ADD PRIMARY KEY (keycolumn);')
Unfortunately, pandas.to_sql doesn't set primary key, it even also destructs the primary key of existing table. One must aware for the primary keys.
When dropping constraints from a postgres table , How to know the safest order to drop the constraints. Like ,
1) The foreign key constraints can be dropped first [as they have to be droppped before primary key constraint]
Then the order of removing the constraints can be in any order . like check constraint, unique constraint, not nulls, default , primary key constraints . Am I correct
No constraint on a PostgreSQL table depends on another constraint on the same table, so the order does not matter here.
The only dependency between constraints is the dependency of a foreign key on the primary or unique key on the target table.
So you can either remove all foreign key constraints first and then all other constraints, or you can use ALTER TABLE ... DROP CONSTRAINT ... CASCADE which will automatically drop all dependent constraints, then you don't have to care about the order at all.
Can I have two tables with different constrains that are names the same - that is:
Table A with constraint C
Table B with constraint C
The constrains are different
Thanks!
I couldn't find any suitable reference in the documentation but it would seem that the uniqueness of the constraint name depends on the type of constraint.
unique and primary key constraint names must be unique and may not be reused in multiple tables, but check and foreign key constraint names can be used in multiple tables (although that might be a bad idea for obvious reasons).
I would guess that the reason is that unique and primary key constraints create indexes and therefore needs to be uniquely named.
I didn't find where is it mentionned in postgres documentation. Here's a confirmation that constraint name but be different in the database.
CREATE TABLE type_position(
type_position INTEGER CONSTRAINT pk_type_position PRIMARY KEY,
description VARCHAR( 64 )
);
CREATE TABLE type_position2(
type_position INTEGER CONSTRAINT pk_type_position PRIMARY KEY,
description VARCHAR( 64 )
);
And I got the message
ERROR: relation "pk_type_position" already exists