We're in the process of upgrading our software from PostgreSQL 9.2 to 9.6 and we've run into an odd issue.
Our installation runs an SQL script to create the database. This is done using psql -f. This worked fine under 9.2 but seems to have issues with not creating objects in 9.6. I've been looking into this and found something odd in the SQL script. Most of the tables are created using statements that look like this:
--
-- Name: crawler_run; Type: TABLE; Schema: analytics; Owner: postgres; Tablespace:
--
CREATE TABLE IF NOT EXISTS crawler_run (
... columns, etc.
);
--
ALTER TABLE analytics.crawler_run OWNER TO postgres;
Note that there is no schema in the create table statement. But the tables were being created in the correct schema and the subsequent alter table statement was not failing.
My best guess is that the preceding comment has something to do with it, but I've not been able to find any documentation to support that.
So how was this working?
Tables are created in the first schema of the user/role search_path, which is either set permanently or just for the current session.
Look for a statement like:
SET search_path = analytics
In your case it was analytics and now it is probably back to the default public.
Related
I have a SQL ALTER statement to update an existing publication to add a table.
ALTER PUBLICATION publication_p1 ADD TABLE schema.tablename;
I want to add this line to an automated database versioning script. However I want to see if the publication would be added IF the table wasn't a member AND if the publication existed. So something like:
ALTER PUBLICATION IF EXISTS publication_p1 ADD TABLE IF NOT EXISTS schema.tablename;
I tried my idea, and obviously didn't work. Looking at the postgres documentation IF EXISTS is not supported.
Is there a way of applying something similar in POSTGRES?
Thanks
I'm extremely new to PostgreSQL and I just installed it using Homebrew.
I ran through creating and connecting to a database and now I'm trying to create a table with the standard command CREATE TABLE users(name string, age smallint, birthday date) and the command completes. However as soon as I run the command to list all tables I get the following Did not find any relations.
I checked all users and privileges and it looks like my profiles roles include Superuser, Create Role, Create DB, Replication, Bypass RLS and I'm a member of {}.
I'm not sure if there's something more I need to do in order to create tables under a certain database or not, but I've looked all over and can't seem to find an answer to this.
I'm not really sure what you're intending to do, be more explicit.
But it seems to me you've juste created tables and did not create any relations.
Try using a key and defining mother tables ?
I have a table named import.
I want to rename the table with the following statement in a sql script below.
Unfortunately I can't, because sql treats the term import as a psql keyword.
How can I change the name in a sql script?
I have a Database change management also called database migration or database upgrading. Database change management is the process of managing the change of a database over the course of an application's lifecycle. What could change in a database? The database structure (i.e. the tables), master data but even indices, triggers and stored procedures could be added, changed or deleted over time.
ALTER TABLE import
RENAME TO api_exchange;
I am aware I can change the table name with a PostgreSQL client, but I need to do it in a SQL script for postgreSQL 10 in order to keep my Database change management intact.
You can quote reserved words using double quotes:
-- \i tmp.sql
CREATE TABLE "select"(id integer);
ALTER TABLE "select"
RENAME TO api_exchange;
\d api_exchange
I've a script like the following:
SET search_path = MySchema;
INSERT INTO MyTable() values ()
MyTable is actually created in MySchema, so if I change the script to
INSERT INTO MySchema.MyTable() values ()
It works
Now I'm generating some SQL files to recreate a database structure, so we have the scripts generated with "SET search_path = MySchema;"
Is there a way to make this work?
Using NPGSQL version 3.0.4.0
My mistake, it's not related to the schema itself, the issue is when having both DDL and DML instructions together.
Encountered this issue when trying to modify the search_path to my new Redshift db.
Presently, I've migrated the contents of my MySQL db into a redshift cluster via AWS' Data Migration Service. The data was imported into a schema lets call my_schema. When I try to execute queries against the cluster it requires me to prefix table names with the schema name
i.e.
select * from my_schema.my_table
I wanted to change the setup so that I can reference the table directly without needing the prefix. After a bit of looking around I found out that this was possible by modifying the search_path attribute.
First I tried doing this by running
set search_path = "$user", my_schema;
This appeared to work but then I realized that this was simply setting my_schema as the default schema in the context of the current session, I wanted it set on a database level. I found several sources saying that the way to do this was to use the alter command like so...
alter database my_db set search_path = "$user", public, my_schema
However, running this command results in the following error which somehow shows up in 0 google results:
SET/RESET commmand in ALTER DATABASE is not supported
I'm pretty baffled by how the above error hasn't ever had a post made about it but I'm also pretty interested in figuring out how to resolve my initial issue of setting a global default schema for my redshift cluster.
ALTER DATABASE SET is not supported in Redshift. However you can SET/RESET configuration parameters at USER level using the ALTER USER SET SEARCH_PATH TO <SCHEMA1>,<SCHMEA2>;
Please check: http://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_USER.html
http://docs.aws.amazon.com/redshift/latest/dg/r_search_path.html
When you set the search_path to <SCHEMA1>,<SCHMEA2> in db1 for a user it is not for just current session, it will be set for all future sessions.