I’m having this strange problem using PostgreSQL 9.3 with tables that are created using qoutes. For instance, if I create a table using qoutes:
create table "TEST" ("Col1" bigint);
the table is properly created and I can see that the quotes are preserved when view it in the SQL pane of pgAdminIII. But when I query the DB to find the list of all available tables (using the below query), I see that the result does not contain quotes around the table name.
select table_schema, table_name from information_schema.tables where not table_schema='pg_catalog' and not table_schema='information_schema';
Since the table was created with quotes, I can’t use the table name returned from the above query directly since it is unquoted and throws the error in posted in the title.
I could try surrounding the table names with quotes in all queries but I’m not sure if it’ll work all the time. I’m looking for a way to get the list of table names that are quoted with quotes in the result.
I’m having the same issue with column names as well but I’m hoping that if I can find a solution to the table names issue, a similar solution will work for column names as well.
PostgreSQL error 42P01 actually makes users dumbfounded, especially the newbies.
Usually, this error occurs due to an undefined table in newly created databases.
That’s why at Bobcares, we often get requests to fix PostgreSQL errors, as a part of our Server Management Services.
Today, let’s have a look into the PostgreSQL error 42P01 and see how our Support Engineers fix it.
What is PostgreSQL error 42P01?
PostgreSQL has a well-defined error code description. This helps in identifying the reason for the error.
Today, let’s discuss in detail about PostgreSQL error 42P01. The typical error code in PostgreSQL appears as:
ERROR: relation "[Table name]" does not exist
SQL state:42P01
Here the 42P01 denotes an undefined table.
So, the code description clearly specifies the basic reason for the error.
But what does an undefined table means?
Let’s discuss it in detail.
Causes and fixes for the PostgreSQL error 42P01
Customer query on undefined tables of a database often shows up the 42P01 error.
Now let’s see a few situations when our customers get the 42P01 error. We will also see how our Support Engineers fix this error.
1. Improper database setup
Newbies to Postgres often make mistakes while creating a new database. Mostly, this improper setup ends up in a 42P01 error.
In such situations, our Support Team guides them for easy database setup.
Firstly, we create a new database. Next, we create a new schema and role. We give proper privileges to tables.
Postgres also allows users to ALTER DEFAULT PRIVILEGES.
2. Unquoted identifiers
Some customers create tables with mixed-case letters.
Usually, the unquoted identifiers are folded into lowercase. So, when the customer queries the table name with the mixed case it shows 42P01 error.
The happens as the PostgreSQL has saved the table name in lower case.
To resolve this error, our Support Engineers give mixed case table name in quotes. Also, we highly recommend to NOT use quotes in database names. Thus it would make PostgreSQL behave non-case sensitive.
3. Database query on a non-public schema
Similarly, the PostgreSQL 42P01 error occurs when a user queries a non-public schema.
Usually, this error occurs if the user is unaware of the proper Postgres database query.
For instance, the customer query on table name ‘pgtable‘ was:
SELECT * FROM pgtable
This query is totally correct in case of a public schema. But, for a non-public schema ‘xx’ the query must be:
SELECT * FROM "xx"."pgtable"
Hence, our Support Engineers ensure that the query uses the correct schema name.
[Still having trouble in fixing PostgreSQL errors? – We’ll fix it for you.]
Conclusion
In short, PostgreSQL error 42P01 denotes the database query is on an undefined table. This error occurs due to improper database setup, unidentified table name, and so on. Today, we saw how our Support Engineers fix the undefined table error in Postgres.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
GET STARTED
var google_conversion_label = «owonCMyG5nEQ0aD71QM»;
What you had originally was a correct syntax — for tables, not for schemas. As you did not have a table (dubbed ‘relation’ in the error message), it threw the not-found error.
I see you’ve already noticed this — I believe there is no better way of learning than to fix our own mistakes
But there is something more. What you are doing above is too much on one hand, and not enough on the other.
Running the script, you
- create a schema
- create a role
- grant
SELECT
on all tables in the schema created in (1.) to this new role_ - and, finally, grant all privileges (
CREATE
andUSAGE
) on the new schema to the new role
The problem lies within point (3.) You granted privileges on tables in replays
— but there are no tables in there! There might be some in the future, but at this point the schema is completely empty. This way, the GRANT
in (3.) does nothing — this way you are doing too much.
But what about the future tables?
There is a command for covering them: ALTER DEFAULT PRIVILEGES
. It applies not only to tables, but:
Currently [as of 9.4], only the privileges for tables (including views and foreign tables), sequences, functions, and types (including domains) can be altered.
There is one important limitation, too:
You can change default privileges only for objects that will be created by yourself or by roles that you are a member of.
This means that a table created by alice
, who is neither you nor a role than you are a member of (can be checked, for example, by using du
in psql
), will not take the prescribed access rights. The optional FOR ROLE
clause is used for specifying the ‘table creator’ role you are a member of. In many cases, this implies it is a good idea to create all database objects using the same role — like mydatabase_owner
.
A small example to show this at work:
CREATE ROLE test_owner; -- cannot log in
CREATE SCHEMA replays AUTHORIZATION test_owner;
GRANT ALL ON SCHEMA replays TO test_owner;
SET ROLE TO test_owner; -- here we change the context,
-- so that the next statement is issued as the owner role
ALTER DEFAULT PRIVILEGES IN SCHEMA replays GRANT SELECT ON TABLES TO alice;
CREATE TABLE replays.replayer (r_id serial PRIMARY KEY);
RESET ROLE; -- changing the context back to the original role
CREATE TABLE replays.replay_event (re_id serial PRIMARY KEY);
-- and now compare the two
dp replays.replayer
Access privileges
Schema │ Name │ Type │ Access privileges │ Column access privileges
─────────┼──────────┼───────┼───────────────────────────────┼──────────────────────────
replays │ replayer │ table │ alice=r/test_owner ↵│
│ │ │ test_owner=arwdDxt/test_owner │
dp replays.replay_event
Access privileges
Schema │ Name │ Type │ Access privileges │ Column access privileges
─────────┼──────────────┼───────┼───────────────────┼──────────────────────────
replays │ replay_event │ table │ │
As you can see, alice
has no explicit rights on the latter table. (In this case, she can still SELECT
from the table, being a member of the public
pseudorole, but I didn’t want to clutter the example by revoking the rights from public
.)
I’m new at creating databases, and this error has me dumbfounded, as I am super new with DB admin things (I mostly do reporting type queries). I created a new database through pgAdmin3 GUI, and I’m trying to create DB objects in there using SQL but am getting a:
ERROR: relation "replays" does not exist SQL state: 42P01
I looked through the manual but did not find anything very helpful, though I suspect it may have to do with search_path
somehow. Here is a screenshot. Any idea what I’m doing wrong please?
Im trying to autogenerate INSERT statements to populate a table from a given list of names and products using c# and Npgsql. Everything was working fine, so I decided to add couple of triggers that are needed for the purpose of this project. Triggers are relatively simple, but they performed flawlesly, while testing them on the sql console. Then, when I finally thought I was finished with the assignment, I tested it once again with my auto populating method in C#.I got this as an error:
Npgsql.PostgresException: ’42P01: relation «buyer» does not exist’
I’ve decided to test it once again on console, using the exact same INSERT statement, and again, it worked as it should have from the start. After good 3-4h spent googling and finding little to no answers, I’ve disabled all triggers and then the c# script worked without any problems.
So, to sum things up, query works with triggers flawlesly while typed in the console, but when used in C# it can’t find the table?.
CREATE OR REPLACE FUNCTION "TBP_ERA".trigger_dohvati_prvi_datum()
RETURNS trigger
LANGUAGE plpgsql
AS $function$
BEGIN
insert into "TBP_ERA".order(orderer,productname,productquantity)
select buyer.id,buyer.productname,buyer.productquantity from buyer where buyer.ordercompleted=0 order by orderedat asc fetch first 1 rows only;
return null;
END;
$function$
;
And the trigger itself:
create
trigger dohvati_datum after insert
on
"TBP_ERA".buyer for each row execute procedure trigger_dohvati_prvi_datum();
EDIT:
C# part of the INSERT code
connection.Open();
NpgsqlCommand command = new NpgsqlCommand("INSERT INTO "TBP_ERA".buyer(ID,name,productname,productquantity,ordercompleted)" +
" VALUES(default,'" + buyer.Name + "','" + buyer.ProductName + "'," + buyer.ProductQuantity+",0);", connection);
try
{
command.ExecuteNonQuery();
}
catch (NpgsqlException ex)
{
string nekej = ex.ToString();
throw;
}
connection.Close();