Postgresql 42p01 ошибка отношение не существует

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.

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

1. create a schema
2. create a role
3. grant SELECT on all tables in the schema created in (1.) to this new role_
4. and, finally, grant all privileges (CREATE and USAGE) 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.)