PGVector is a good extension that Just Works within PostgreSQL, with all batteries included for a PostgreSQL cluster to operate. To me, this means pgvector supports full snapshot consistency, streaming replication, point-in-time recovery, basebackups, etc.
This "pgvector-remote" fork, however, is now fundamentally incompatible with pgvector: while it installs mostly the same features as pgvector (plus some more); it critically installs the same access methods that pgvector installs, using the same name. As access methods can't be renamed and their names are supposed to be unique and database-global namespaced (so not schema-namespaced like table names), this results in conflicts when you want to use both extensions; which is reasonable, considering pgvector's progress.
So, what's the rationale for choosing to Fork, rather than Extend?
PGVector is a good extension that Just Works within PostgreSQL, with all batteries included for a PostgreSQL cluster to operate. To me, this means
pgvectorsupports full snapshot consistency, streaming replication, point-in-time recovery, basebackups, etc.This "pgvector-remote" fork, however, is now fundamentally incompatible with pgvector: while it installs mostly the same features as pgvector (plus some more); it critically installs the same access methods that pgvector installs, using the same name. As access methods can't be renamed and their names are supposed to be unique and database-global namespaced (so not schema-namespaced like table names), this results in conflicts when you want to use both extensions; which is reasonable, considering pgvector's progress.
So, what's the rationale for choosing to Fork, rather than Extend?