This error occurs when PostgreSQL cannot find a table, view, or other relation with the specified name. It's usually caused by schema issues, case sensitivity problems, typos, or incorrect database connections. Fix by verifying the table exists, checking exact naming and case, specifying the correct schema, or adjusting search_path settings.
In PostgreSQL, a 'relation' refers to any database object like tables, views, sequences, or indexes. When you get this error, it means PostgreSQL looked for the specified relation in the current search path (typically the public schema) but couldn't find it. The database doesn't see the table you're trying to query, which could happen for several reasons including the table existing in a different schema, case sensitivity issues, or the table simply not existing.
Use the psql command line tool or query the information schema to check if the table exists:
\dtOr use this SQL query:
SELECT table_name FROM information_schema.tables WHERE table_schema = 'public';If your table is in a different schema, modify the query:
SELECT table_name FROM information_schema.tables WHERE table_schema = 'your_schema_name';PostgreSQL is case-insensitive for unquoted identifiers but case-sensitive for quoted identifiers. If the table name contains uppercase letters, you may need to quote it:
-- If table was created without quotes (case-insensitive)
SELECT * FROM users; -- works
SELECT * FROM USERS; -- also works
-- If table was created WITH quotes (case-sensitive)
SELECT * FROM "MyTable"; -- must use exact casing
SELECT * FROM "mytable"; -- failsFind the exact table name in your schema:
SELECT schemaname, tablename FROM pg_tables WHERE tablename ILIKE 'your_table_name';If the table exists in a schema other than "public", reference it with the schema name:
-- Incorrect (looks in public schema by default)
SELECT * FROM orders;
-- Correct (if orders is in app_schema)
SELECT * FROM app_schema.orders;Alternatively, set the search_path for your session:
SET search_path TO app_schema, public;
SELECT * FROM orders; -- now worksOr permanently set it in your connection:
ALTER ROLE your_user SET search_path TO app_schema, public;Ensure you're connected to the correct database:
# Check current database
\c
# Connect to correct database
psql -U username -d correct_database_name -h localhostIf using an application connection string, verify:
- Host is correct
- Port is correct (default is 5432)
- Database name matches where the table was created
- Username has access to that database
Verify that your database user has the necessary permissions to access the table:
-- View permissions
\dp table_name
-- Grant SELECT permission
GRANT SELECT ON table_name TO your_user;
-- Grant all permissions
GRANT ALL PRIVILEGES ON table_name TO your_user;If the table is in a non-public schema, also ensure you have USAGE permission on the schema:
GRANT USAGE ON SCHEMA schema_name TO your_user;To avoid this error in the future:
Recommended approach:
- Always use lowercase, unquoted table names: CREATE TABLE users (...)
- This makes PostgreSQL fold all references to lowercase automatically
- Use underscores for multi-word names: user_profiles, product_orders
-- Good: simple, unambiguous
CREATE TABLE users (
id SERIAL PRIMARY KEY,
email VARCHAR(255)
);
SELECT * FROM users; -- always works
SELECT * FROM USERS; -- also works
-- Avoid: quoted names create case sensitivity
CREATE TABLE "Users" (...); -- creates case-sensitive table
SELECT * FROM "Users"; -- must use exact casingIn PostgreSQL, the default search_path is typically '"$user", public'. This means PostgreSQL first looks for objects in a schema matching your username, then in the public schema. When working with ORM tools (Prisma, SQLAlchemy, etc.), schema visibility depends on the connection string configuration. Some tools allow you to specify an initial schema - if this is set incorrectly, you may get this error even if the table exists in a different schema. For Prisma, use the schema parameter in the connection string: postgresql://user:password@localhost/db?schema=myschema. When using views instead of tables, the same error applies if the view doesn't exist or isn't in your search path.
ERROR: syntax error at end of input
Syntax error at end of input in PostgreSQL
Bind message supplies N parameters but prepared statement requires M
Bind message supplies N parameters but prepared statement requires M in PostgreSQL
Multidimensional arrays must have sub-arrays with matching dimensions
Multidimensional arrays must have sub-arrays with matching dimensions
ERROR: value too long for type character varying
Value too long for type character varying
insufficient columns in unique constraint for partition key
How to fix "insufficient columns in unique constraint for partition key" in PostgreSQL