PostgreSQL 9.6. Issue dropping index - postgresql

In a legacy PostgreSQL DB I tried to drop an existing index issuing the command:
DROP INDEX testing.idx_testing_data_model_output_data_id;
and see the error:
ERROR: index "<index name>" does not exist
But I can see the index using the \d <table name> command:
leg=# \d testing.data_model
Table "testing.data_model"
Column | Type | Modifiers
----------------+-----------------------------+---------------------------------------------------------------------------
id | bigint | not null default nextval('testing.data_model_id_seq'::regclass)
input_data | text |
output_data_id | bigint |
Indexes:
"pk_testing_data_model" PRIMARY KEY, btree (id)
"idx_testing_data_model_output_data_id" btree (output_data_id)
Ok, when I try to create the index I receive the following error:
ERROR: relation "<index name>" already exists
It seems that somehow the index creation or index dropping was not successfully complete. How can I resolve this issue?

SET search_path = <schema_name>;
Setting search_path worked for me.

Related

Bigint error when copying .csv to postgresql

Trying to import a .csv into my postgres table using the following approach:
System: WSL2 - UBUNTU 20.04
psql -d db_name --user=username -c "\copy test_list FROM 'testmngrs.csv' delimiter '|' csv;"
The content format of my .csv:
1,Name,name#store_id.com,1234567891,City Name
The error I'm receiving:
ERROR: invalid input syntax for type bigint:
CONTEXT: COPY test_list, line 1, column id:
The table:
SELECT * FROM test_list;
id | store_id | name | email | phone | city
The additional id at the head of the table above was not something created during my initial set up of the table.
My ecto migration file is as follows:
I'm not sure what's causing the BigInt error, nor how to avoid it as I copy over the data. I'm also a bit confused as to why there's an additional id column in my table given that it was never defined in my migration
I'm pretty new to postgresql and elixir / ecto so any assistance is greatly/guidance/context is greatly appreciated!
From the docs:
By default, the table will also include an :id primary key field that has a type of :bigserial.
Ecto assumes you want it to generate the id field by default. It's better to just go with it. But you can configure it somewhat counter-intuitively by setting primary_key: false on the table, and primary_key: true on the column:
create table(:managers, primary_key: false) do
add :store_id, :integer, null: false, primary_key: true
...

Timescale: ERROR: tried calling catalog_get when extension isn't loaded

I'm using Timescale and today I faced on a problem:
I`m creating a simple table with any of bellow ways:
1-
> create table if not exists "NewTable" as (select * from "OldTable");
SELECT 6
2-
create table "NewTable" ("eventTime" timestamptz, name varchar);
after the table successfully created. I write \d and the result for both tables are same:
Column | Type | Collation | Nullable | Default
-----------+--------------------------+-----------+----------+---------
eventTime | timestamp with time zone | | |
name | character varying | | |
but the problem starts here...
> SELECT create_hypertable('"NewTable"', '"eventTime"' ,migrate_data => true);
ERROR: tried calling catalog_get when extension isn't loaded
so after I googled my issue I found nothing usefull insted of everyone told to create timescaledb extention that I had it before
> CREATE EXTENSION timescaledb CASCADE; //OR CREATE IF NOT EXISTS EXTENSION timescaledb CASCADE;
ERROR: extension "timescaledb" has already been loaded with another version
and
> \dx
Name | Version | Schema | Description
-------------+---------+------------+--------------------------------------------------------
plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language
timescaledb | 1.5.1 | public | Enables scalable inserts and complex queries for time-series data
so what should I do?
Question : why this happened? how should I create a hyper table now?
before these operations, I tried to take a dump from my database and before that, I have 20 main_hyper_tables.
why this happened?
I guess TimescaleDB was installed in the standard way through apt. Since new version of TimescaleDB (v.1.6) was released recently, apt automatically updated installation and copied the binary of 1.6 into the shared library of PostgreSQL installation. Thus new extension version was loaded, which is different from the extension used to create the database (v.1.5.1).
how should I create a hyper table now?
I see two options:
Load the extension version used to create the database, by explicitly specifying in the postgres config.
Update the extension to the latest version by
ALTER EXTENSION timescaledb UPDATE
See using ALTER EXTENSION section in Update TimescaleDB doc

Create an automatically increasing primary key column in PostgreSQL

I am following the examples in CREATE TABLE:
CREATE TABLE distributors (
did integer PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
name varchar(40) NOT NULL CHECK (name <> '')
);
However, it gives me ERROR: syntax error at or near "GENERATED". Why is that and how should I fix it?
\! psql -V returns psql (PostgreSQL) 10.5 (Ubuntu 10.5-1.pgdg14.04+1)
SELECT version(); returns PostgreSQL 9.4.19 on x86_64-pc-linux-gnu (Ubuntu 9.4.19-1.pgdg14.04+1), compiled by gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4, 64-bit
Edits:
Thanks to #muistooshort, I checked the 9.4 docs. So I execute:
CREATE TABLE distributors (
did integer PRIMARY KEY DEFAULT nextval('serial'),
name varchar(40) NOT NULL CHECK (name <> '')
);
Nevertheless, it now gives me ERROR: relation "serial" does not exist...
The SQL standard IDENTITY was added in PostgreSQL 10 but your server (which does all the real work) is 9.4. Before 10 you have to use serial or bigserial types:
CREATE TABLE distributors (
did serial not null primary key,
name varchar(40) NOT NULL CHECK (name <> '')
);
The serial type will create a sequence to supply values, attach the sequence to the table, and hook up a default value for did to get values from the sequence.

CSVSQL - trying to force db-schema without success after getting (in table 'blabla', column 'xyz'): VARCHAR requires a length on dialect mysql

I'm trying to build a table with csvsql.
When I use command:
csvsql --db mysql://user:password#localhost:3306/database_name --table table_name file.csv
I get the error:
(in table 'blabla', column 'xyz'): VARCHAR requires a length on dialect mysql
I've then tried to build a database schema and force it with --db-schema flag,
The db-schema format is:
CREATE TABLE table_name (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`x` varchar(29) DEFAULT NULL,
`y` int(10) NOT NULL DEFAULT '0',
`z` BOOL NOT NULL,
PRIMARY KEY (`id`),
KEY `indexed` (`indexed`)
);
but I still get the same error.
The complete command with db-schema is:
csvsql --db mysql://user:password#localhost:3306/database_name --table table_name --db-schema db_schema_filename csvfile.csv
I've read the manual for csvkit, but I don't get what I'm doing wrong.
This command should print the conversion result right?
Can someone please help?
Thank you.
Well, found the solution in the github.
https://github.com/wireservice/csvkit/issues/758#issue-201924611
After update from github, no more errors and tables are created normaly.

Extension exists but uuid_generate_v4 fails

At amazon ec2 RDS Postgresql:
=> SHOW rds.extensions;
rds.extensions
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
btree_gin,btree_gist,chkpass,citext,cube,dblink,dict_int,dict_xsyn,earthdistance,fuzzystrmatch,hstore,intagg,intarray,isn,ltree,pgcrypto,pgrowlocks,pg_trgm,plperl,plpgsql,pltcl,postgis,postgis_tiger_geocoder,postgis_topology,sslinfo,tablefunc,tsearch2,unaccent,uuid-ossp
(1 row)
As you can see, uuid-ossp extension does exist. However, when I'm calling the function for generation uuid_v4, it fails:
CREATE TABLE my_table (
id uuid DEFAULT uuid_generate_v4() NOT NULL,
name character varying(32) NOT NULL,
);
What's wrong with this?
The extension is available but not installed in this database.
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
If the extension is already there but you don't see the uuid_generate_v4() function when you do a describe functions \df command then all you need to do is drop the extension and re-add it so that the functions are also added. Here is the issue replication:
db=# \df
List of functions
Schema | Name | Result data type | Argument data types | Type
--------+------+------------------+---------------------+------
(0 rows)
CREATE EXTENSION "uuid-ossp";
ERROR: extension "uuid-ossp" already exists
DROP EXTENSION "uuid-ossp";
CREATE EXTENSION "uuid-ossp";
db=# \df
List of functions
Schema | Name | Result data type | Argument data types | Type
--------+--------------------+------------------+---------------------------+--------
public | uuid_generate_v1 | uuid | | normal
public | uuid_generate_v1mc | uuid | | normal
public | uuid_generate_v3 | uuid | namespace uuid, name text | normal
public | uuid_generate_v4 | uuid | | normal
db=# select uuid_generate_v4();
uuid_generate_v4
--------------------------------------
b19d597c-8f54-41ba-ba73-02299c1adf92
(1 row)
What probably happened is that the extension was originally added to the cluster at some point in the past and then you probably created a new database within that cluster afterward. If that was the case then the new database will only be "aware" of the extension but it will not have the uuid functions added which happens when you add the extension. Therefore you must re-add it.
Looks like the extension is not installed in the particular database you require it.
You should connect to this particular database with
\CONNECT my_database
Then install the extension in this database
CREATE EXTENSION "uuid-ossp";
Step #1: re-install uuid-ossp extention into the exact schema:
If this is a fresh installation you can skip SET and DROP. Credits to #atomCode (details)
SET search_path TO public;
DROP EXTENSION IF EXISTS "uuid-ossp";
CREATE EXTENSION "uuid-ossp" SCHEMA public;
After this, you should see uuid_generate_v4() function IN THE RIGHT SCHEMA (when execute \df query in psql command-line prompt).
Step #2: use fully-qualified names (with schemaname. qualifier):
For example:
CREATE TABLE public.my_table (
id uuid DEFAULT public.uuid_generate_v4() NOT NULL,
If you've changed the search_path, specify the public schema in the function call:
public.uuid_generate_v4()
This worked for me.
create extension IF NOT EXISTS "uuid-ossp" schema pg_catalog version "1.1";
make sure the extension should by on pg_catalog and not in your schema...
Just add this code to the Beginning of your script
DROP EXTENSION IF EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
Maybe It was the same I was facing. The uuid_generate_v4 was from the public schema and I was trying to run it in a specific schema, so to fix it I did:
SET search_path TO specific_schema;
INSERTO INTO my_table VALUES public.uuid_generate_v4();
You can check the schema where your function is running:
\df uuid_generate_v4
Or
SELECT n.nspname, p.probin, p.proname
FROM
pg_proc p
LEFT JOIN pg_namespace n ON p.pronamespace = n.oid
WHERE p.proname like 'uuid_generate_v4';
You can check info related to the extension of the uuid-ossp like this:
SELECT * FROM pg_extension WHERE extname LIKE 'uuid-ossp';
You can add this extension case you don't have it already:
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
if you do it from unix command (apart from PGAdmin) dont forget to pass the DB as a parameter. otherwise this extension will not be enabled when executing requests on this DB
psql -d -c "create EXTENSION pgcrypto;"
in my case were 3 steps. Create the database, connect to the database and create the extension. The important step is the second one, "connect to the database", and you can notice the line without ";" cause is a command and not a SQL sentence.
CREATE DATABASE database_name_here;
\connect database_name_here
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";