This error occurs when you try to reference a table from a different database using the three-part naming convention (database.schema.table). PostgreSQL does not support cross-database queries directly. Instead, use schemas within a single database or the postgres_fdw extension to connect to other PostgreSQL servers.
PostgreSQL has a different architecture than some other SQL databases (like SQL Server or MySQL). In PostgreSQL, you cannot reference tables in other databases the way you might in SQL Server using four-part naming (server.database.schema.table). PostgreSQL enforces that you must be connected to a specific database to query it. While you can use the three-part naming syntax (database.schema.table) for syntactic compliance with the SQL standard, PostgreSQL interprets it as a schema reference, not a database reference. If the database name does not match the currently connected database, PostgreSQL raises this error because the architecture does not support cross-database references at the query level.
PostgreSQL requires you to connect to a specific database. All queries in that connection operate on that database. Unlike SQL Server which allows cross-database queries in a single session, PostgreSQL does not have this feature.
You can verify your current database:
SELECT current_database();All queries must reference tables within this database.
Change three-part table references to two-part references.
Wrong (causes the error):
SELECT * FROM myDatabase.public.users;Correct:
SELECT * FROM public.users;If you are already connected to myDatabase, you do not need to specify the database name. The public schema is the default schema in PostgreSQL.
If you have been using multiple databases for organizational purposes (like in MySQL), migrate to using schemas within a single database.
Create separate schemas:
CREATE SCHEMA app_schema;
CREATE SCHEMA archive_schema;Reference tables with schema prefix:
SELECT * FROM app_schema.users;
SELECT * FROM archive_schema.old_orders;This gives you logical separation without requiring cross-database queries. You can even set your search_path to include multiple schemas:
SET search_path TO app_schema, archive_schema, public;Then reference tables by name alone (PostgreSQL searches the path in order).
If you need to query tables from a different PostgreSQL database (possibly on a different server), use the postgres_fdw (foreign data wrapper) extension.
Install the extension:
CREATE EXTENSION postgres_fdw;Create a foreign server connection:
CREATE SERVER remote_db
FOREIGN DATA WRAPPER postgres_fdw
OPTIONS (host 'remote.example.com', dbname 'remote_database', port '5432');Create a user mapping:
CREATE USER MAPPING FOR postgres
SERVER remote_db
OPTIONS (user 'remote_user', password 'remote_password');Import the remote schema:
IMPORT FOREIGN SCHEMA public
FROM SERVER remote_db
INTO local_schema;Query the remote tables:
SELECT * FROM local_schema.remote_table;If migrating code from SQL Server that uses cross-database references:
SQL Server (does not work in PostgreSQL):
SELECT * FROM database1.dbo.table1
JOIN database2.dbo.table2 ON table1.id = table2.id;PostgreSQL approach (one database, multiple schemas):
SELECT * FROM db1_schema.table1
JOIN db2_schema.table2 ON table1.id = table2.id;Or consolidate into a single schema if appropriate:
SELECT * FROM public.table1
JOIN public.table2 ON table1.id = table2.id;Update all your queries to use schema.table notation instead of database.schema.table.
Performance considerations: postgres_fdw is useful for querying remote PostgreSQL databases but involves network overhead. For frequently accessed remote data, consider materializing views or replicating data to your primary database. Alternative solutions include using dblink (older method) or logical replication for keeping databases synchronized. If you are using a managed PostgreSQL service (AWS RDS, Google Cloud SQL, Azure), check if postgres_fdw is enabled; some services restrict or disable it for security reasons. For very large cross-database queries, consider redesigning your schema to use a single database with appropriate partitioning or sharding strategies.
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