I added the ltree extension and I can see the extension in my db but when I run the following query:
CREATE TABLE flight_office.document_folder (
document_folder_id serial8,
name varchar,
path ltree,
PRIMARY KEY (document_folder_id)
);
I get this:
ERROR: type "ltree" does not exist
Probably your schema is not included in the search_path.
To install the ltree extension in a schema different from public there are some steps to be done. Let's say your schema is called "myschema":
First create the schema and install the extension:
CREATE SCHEMA myschema;
CREATE EXTENSION IF NOT EXISTS ltree
WITH SCHEMA myschema;
You can check the last step with
SELECT *
FROM information_schema.schemata
WHERE schema_name = 'myschema';
SELECT *
FROM pg_available_extensions
WHERE name = 'ltree';
and
SELECT *
FROM pg_extension;
select *
from pg_catalog.pg_namespace;
where extowner indicates what is the schema where the extension is available.
Then, check whether myschema belongs to the search_path:
SHOW search_path;
; if not add your schema to it:
SET search_path TO "$user", public, myschema;
the latter set the search_path only for the session. If you want to set it permanently use
ALTER DATABASE <DATABASE_NAME> SET search_path TO "$user", public, myschema;
Finally try to create a table:
create table myschema.temptable (
id INTEGER PRIMARY KEY,
path ltree UNIQUE
);
and add some values:
INSERT INTO myschema.temptable (id, path)
values (1, 'root');
As pointed by #pozs, EXTENSION should be added along with the schema,The following worked for me:
CREATE EXTENSION IF NOT EXISTS LTREE
WITH SCHEMA schema_name;
This also works. It will create the extension for the public schema, if no schema is specified.
CREATE EXTENSION IF NOT EXISTS ltree;
Related
I'm trying to avoid using PGSQL for some simple queries, but I want to store the schema name as a variable and use it later in multiple queries:
WITH p AS (SELECT 'testSchema' AS schemaName)
CREATE SCHEMA IF NOT EXISTS p.schemaName;
create table if not exists p.schemaName.table1;
Perhaps "with" is not the right way, or may by I need to use it differently.
You should use the SQL statement SET, perhaps with the LOCAL option, but that won't work with CREATE SCHEMA.
Something like this:
BEGIN; -- start transaction
CREATE SCHEMA IF NOT EXISTS testschema;
SET LOCAL search_path = 'testschema'; -- only for this transaction
CREATE TABLE IF NOT EXISTS table1 ...; -- will be created in testschema
COMMIT;
I just had an RDS instance spun up to a Postgresql db. The database was created successfully and I am able to connect. Problem is when I run this code:
CREATE SCHEMA hollywood;
CREATE TABLE films (title text, release date, awards text[]);
SELECT * FROM hollywood.films;
This is the output I get:
Schema hollywood created
Table films created
An error occurred when executing the SQL command:
SELECT * FROM hollywood.films
ERROR: relation "hollywood.films" does not exist
What am I missing here? I added double-quotes around the schema name but to no avail. I opened up the permissions for the user thusly but to no avail (bad, I know)
grant all privileges on all tables in schema hollywood to bi;
I added the search path before my select statement thusly:
SET search_path TO hollywood; select....
No change.
Try:
CREATE SCHEMA hollywood;
CREATE TABLE hollywood.films (title text, release date, awards text[]);
SELECT * FROM hollywood.films;
or
CREATE SCHEMA hollywood;
SET search_path TO hollywood;
CREATE TABLE films (title text, release date, awards text[]);
SELECT * FROM films;
I'm using PostgreSQL 9.x, I want to rename a table. This SQL code:
CREATE TABLE new (id int);
ALTER TABLE new RENAME TO old;
DROP TABLE old;
renames the table correctly. But this SQL code:
CREATE SCHEMA domain;
CREATE TABLE domain.old (id int);
ALTER TABLE domain.old RENAME TO domain.new;
fails, with error:
ERROR: syntax error at or near "."
The "." underlined is the one between 'domain' and 'new'
One way to do this:
ALTER TABLE domain.old RENAME TO new
Other way:
SET search_path TO domain;
ALTER TABLE old RENAME TO new;
Documentation for search_path.
SET search_path TO domain;
ALTER TABLE IF EXISTS old_table_name RENAME TO new_table_name;
Switch to your database
machine$\c my_database
Tename the db
my_databse=# alter table old_name rename to new_name;
I have a strange error in Postgres during creation of sequence and linking on existing table.
I tried to execute the following script on existing DB which have a schema named 'testschema':
BEGIN TRANSACTION;
CREATE TABLE testschema.mytable (
id INTEGER,
value VARCHAR(30),
CONSTRAINT pk_mytable PRIMARY KEY (id));
CREATE SEQUENCE testschema.mytable_id_seq;
ALTER TABLE testschema.mytable ALTER COLUMN id SET NOT NULL;
ALTER TABLE testschema.mytable ALTER COLUMN id SET DEFAULT nextval('mytable_id_seq');
COMMIT;
I got the following error for the second ALTER TABLE query:
********** Erreur **********
ERREUR: la relation « mytable_id_seq »
n'existe pas
État SQL :42P01
Error message can be translated by "Relation 'mytable_id_seq' does not exist".
If I try to execute this script without schema (i.e. in the public schema), it works.
I don't understand what it is failing. Does anyone see where the problem is?
Thanks for your help.
Replace:
ALTER TABLE testschema.mytable ALTER COLUMN id SET DEFAULT nextval('mytable_id_seq');
by
ALTER TABLE testschema.mytable ALTER COLUMN id SET DEFAULT nextval('testschema.mytable_id_seq');
By default, objects without using schema quallifier are searched in the schema that are in the search_path variable. by default default, only public schema exists in this variable.
So the simplest way is to use full quallified qualifier when referencing your objects.
Or, you can put your new schema in the path, like this:
SET search_path TO testschema,public;
Source
Postgres 9.2.1 on OSX 10.9.2.
If I run the following crosstab example query:
CREATE EXTENSION tablefunc;
CREATE TABLE ct(id SERIAL, rowid TEXT, attribute TEXT, value TEXT);
INSERT INTO ct(rowid, attribute, value) VALUES('test1','att1','val1');
SELECT *
FROM crosstab(
'select rowid, attribute, value
from ct
where attribute = ''att2'' or attribute = ''att3''
order by 1,2')
AS ct(row_name text, category_1 text, category_2 text, category_3 text);
I get: ERROR: extension "tablefunc" already exists
But if I comment out CREATE EXTENSION
I get: ERROR: function crosstab(unknown) does not exist
How can I get out of this vicious circle? Is it a known issue?
You can change the first line into:
CREATE EXTENSION IF NOT EXISTS tablefunc;
the problem in my case was that the 'tablefunc' extension was defined on one specific schema in my DB, and not accessible to all schemas in it.
[edit: as explained above, 'not accessible to all schemas' should read 'cannot be loaded on all schemas']
I learned that:
the Extension can only be loaded into one schema - so load it into 'public'
you have to manually drop the extension from one schema before you can load it in another
you can list the loaded extensions per schema in pqsl using the command: \df *.crosstab
[edit: 4. you can access the extension either by search_path, by loading it on public schema or by explicitly specifying a schema]
There's a misconception in your answer:
and not accessible to all schemas in it.
All schemas inside the same database are accessible to all sessions in that same database, (as long as privileges are given). It's a matter of setting the search_path. Schemas work much like directories / folders in the file system.
Alternatively, you can schema-qualify the function (and even operators) to access it independently of the search_path:
SELECT *
FROM my_extension_schema.crosstab(
$$select rowid, attribute, "value"
from ct
where attribute IN ('att2', 'att3')
order by 1,2$$
,$$VALUES ('att2'), ('att3')$$
) AS ct(row_name text, category_2 text, category_3 text);
More:
How to use % operator from the extension pg_trgm?
Dubious crosstab()
Your query returned attributes 'att2' and 'att3', but the column definition list had three categories (category_1, category_2, category_3) that do not match the query.
I removed category_1 and added the second parameter to crosstab() - the "safe" version. More details here:
PostgreSQL Crosstab Query
Aside:
Don't use value as column name, even if Postgres allows it. It's a reserved word in standard SQL.