ERROR: `function array_position(smallint[], smallint) does not exist` while pushing schema to `postgres:9.4`
See original GitHub issueBug description
Running prisma db push
against an empty postgres:9.4
instance results in the following error message:
Prisma schema loaded from prisma/schema.prisma
Datasource "db": PostgreSQL database "tests", schema "public" at "localhost:5432"
Error: db error: ERROR: function array_position(smallint[], smallint) does not exist
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
0: sql_migration_connector::flavour::postgres::connection::describe_schema
at migration-engine/connectors/sql-migration-connector/src/flavour/postgres/connection.rs:30
1: migration_core::state::SchemaPush
at migration-engine/core/src/state.rs:349
ERROR Command failed with exit code 1: /Users/jkomyno/Library/pnpm/store/v3/tmp/dlx-54415/node_modules/.bin/prisma db push
pnpm: Command failed with exit code 1: /Users/jkomyno/Library/pnpm/store/v3/tmp/dlx-54415/node_modules/.bin/prisma db push
at makeError (/Users/jkomyno/.nvm/versions/node/v16.15.1/lib/node_modules/pnpm/dist/pnpx.cjs:16527:17)
at handlePromise (/Users/jkomyno/.nvm/versions/node/v16.15.1/lib/node_modules/pnpm/dist/pnpx.cjs:17098:33)
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at async Object.handler [as dlx] (/Users/jkomyno/.nvm/versions/node/v16.15.1/lib/node_modules/pnpm/dist/pnpx.cjs:183480:7)
at async /Users/jkomyno/.nvm/versions/node/v16.15.1/lib/node_modules/pnpm/dist/pnpx.cjs:192579:21
at async run (/Users/jkomyno/.nvm/versions/node/v16.15.1/lib/node_modules/pnpm/dist/pnpx.cjs:192553:34)
at async /Users/jkomyno/.nvm/versions/node/v16.15.1/lib/node_modules/pnpm/dist/pnpx.cjs:192625:5
Here are the logs emitted by the database:
postgres_1 | LOG: database system is ready to accept connections
postgres_1 | ERROR: function array_position(smallint[], smallint) does not exist at character 438
postgres_1 | HINT: No function matches the given name and argument types. You might need to add explicit type casts.
postgres_1 | STATEMENT: WITH rawindex AS (
postgres_1 | SELECT
postgres_1 | indrelid,
postgres_1 | indexrelid,
postgres_1 | indisunique,
postgres_1 | indisprimary,
postgres_1 | unnest(indkey) AS indkeyid,
postgres_1 | generate_subscripts(indkey, 1) AS indkeyidx,
postgres_1 | unnest(indclass) AS indclass,
postgres_1 | unnest(indoption) AS indoption
postgres_1 | FROM pg_index -- https://www.postgresql.org/docs/current/catalog-pg-index.html
postgres_1 | WHERE
postgres_1 | indpred IS NULL -- filter out partial indexes
postgres_1 | AND array_position(indkey::int2[], 0::int2) IS NULL -- filter out expression indexes
postgres_1 | )
postgres_1 | SELECT
postgres_1 | indexinfo.relname AS index_name,
postgres_1 | tableinfo.relname AS table_name,
postgres_1 | columninfo.attname AS column_name,
postgres_1 | rawindex.indisunique AS is_unique,
postgres_1 | rawindex.indisprimary AS is_primary_key,
postgres_1 | rawindex.indkeyidx AS column_index,
postgres_1 | opclass.opcname AS opclass,
postgres_1 | opclass.opcdefault AS opcdefault,
postgres_1 | indexaccess.amname AS index_algo,
postgres_1 | CASE rawindex.indoption & 1
postgres_1 | WHEN 1 THEN 'DESC'
postgres_1 | ELSE 'ASC' END
postgres_1 | AS column_order
postgres_1 | FROM
postgres_1 | rawindex
postgres_1 | INNER JOIN pg_class AS tableinfo ON tableinfo.oid = rawindex.indrelid
postgres_1 | INNER JOIN pg_class AS indexinfo ON indexinfo.oid = rawindex.indexrelid
postgres_1 | INNER JOIN pg_namespace AS schemainfo ON schemainfo.oid = tableinfo.relnamespace
postgres_1 | INNER JOIN pg_attribute AS columninfo
postgres_1 | ON columninfo.attrelid = tableinfo.oid AND columninfo.attnum = rawindex.indkeyid
postgres_1 | INNER JOIN pg_am AS indexaccess ON indexaccess.oid = indexinfo.relam
postgres_1 | LEFT JOIN pg_opclass AS opclass -- left join because crdb has no opclasses
postgres_1 | ON opclass.oid = rawindex.indclass
postgres_1 | WHERE schemainfo.nspname = $1
postgres_1 | ORDER BY schemainfo.nspname, tableinfo.relname, indexinfo.relname, rawindex.indkeyidx;
postgres_1 |
How to reproduce
Consider the following docker-compose.yml
file:
# docker-compose.yml
version: '3.7'
services:
postgres:
image: postgres:9.4
restart: unless-stopped
environment:
- POSTGRES_DB=tests
- POSTGRES_USER=prisma
- POSTGRES_PASSWORD=prisma
ports:
- '5432:5432'
- Run database:
docker-compose up
- Set environment variable:
export DATABASE_URL="postgres://prisma:prisma@localhost:5432/tests"
- Push schema (presented below) to database:
prisma db push
Expected behavior
The schema should be pushed to the database without any error.
The same schema is successfully prisma db push
’d using postgres:10
to postgres:14
.
Notice that array_position
is mentioned in the docs of postgres:10
but not in the docs for postgres:9
.
Prisma information
// ./prisma/schema.prisma
generator client {
provider = "prisma-client-js"
}
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
model Tag {
id Int @id
}
Environment & setup
- OS: Mac OS M1
- Database:
postgres:9.4
- Node.js version:
18.8.0
Prisma Version
prisma : 4.3.1
@prisma/client : 4.3.1
Current platform : darwin-arm64
Query Engine (Node-API) : libquery-engine c875e43600dfe042452e0b868f7a48b817b9640b (at ../../../../../Library/pnpm/store/v3/tmp/dlx-54383/node_modules/.pnpm/@prisma+engines@4.3.1/node_modules/@prisma/engines/libquery_engine-darwin-arm64.dylib.node)
Migration Engine : migration-engine-cli c875e43600dfe042452e0b868f7a48b817b9640b (at ../../../../../Library/pnpm/store/v3/tmp/dlx-54383/node_modules/.pnpm/@prisma+engines@4.3.1/node_modules/@prisma/engines/migration-engine-darwin-arm64)
Introspection Engine : introspection-core c875e43600dfe042452e0b868f7a48b817b9640b (at ../../../../../Library/pnpm/store/v3/tmp/dlx-54383/node_modules/.pnpm/@prisma+engines@4.3.1/node_modules/@prisma/engines/introspection-engine-darwin-arm64)
Format Binary : prisma-fmt c875e43600dfe042452e0b868f7a48b817b9640b (at ../../../../../Library/pnpm/store/v3/tmp/dlx-54383/node_modules/.pnpm/@prisma+engines@4.3.1/node_modules/@prisma/engines/prisma-fmt-darwin-arm64)
Format Wasm : @prisma/prisma-fmt-wasm 4.3.0-32.c875e43600dfe042452e0b868f7a48b817b9640b
Default Engines Hash : c875e43600dfe042452e0b868f7a48b817b9640b
Studio : 0.473.0
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:5 (5 by maintainers)
Top Results From Across the Web
schema does not exist error in Postgresql - Stack Overflow
i have below tables and functions while executing the below function in postgresql ,it is showing ERROR: schema "tblmark" does not exist.
Read more >function array_position(text[], character varying) does not exist ...
I think this is perfectly fine, but I believe there is a limitation here ... CASE WHEN color='Red' THEN 1::smallint WHEN color='Orange' THEN ......
Read more >Documentation: 15: 10.3. Functions - PostgreSQL
If a function is declared with a VARIADIC array parameter, and the call does not use the VARIADIC keyword, then the function is...
Read more >Common Error Messages — Citus 11.1 documentation
Remaining connection slots are reserved for non-replication superuser connections . This occurs when PostgreSQL runs out of available connections to serve ...
Read more >Using a PostgreSQL database as an AWS DMS source
Use a PostgreSQL database as a source for AWS DMS. ... Use any available AWS DMS version. ... Don't end idle transactions when...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Note that 9.6 and older are not supported anymore by The PostgreSQL Global Development Group https://www.postgresql.org/support/versioning/
Given that we discovered this by chance and nobody reported it, what makes the most sense is to change the minimal support of PostgreSQL to 9.6 and up.
We’re happy to revisit this if people show interest in versions 9.4 or 9.5.
PostgreSQL 9.4 is unusable with Migrate / Introspection engines:
migrate dev
https://github.com/prisma/prisma/actions/runs/3337373646/jobs/5523642529#step:10:731migrate diff
https://github.com/prisma/prisma/actions/runs/3337373646/jobs/5523642529#step:10:1124db pull
https://github.com/prisma/prisma/actions/runs/3337373646/jobs/5523642529#step:10:932