[BUG] Wrong database type checking for embedding_column in PGVectorStore.create #88

Closed
opened 2026-02-16 05:16:30 -05:00 by yindo · 4 comments
Owner

Originally created by @NanoClem on GitHub (Aug 6, 2025).

Originally assigned to: @averikitsch on GitHub.

Hello !

I am trying to use the latest features of langchain-postgres as they perfectly answer my need of reusing a pre-existing table.

I think I have stumbled upon a bug during the instanciation of PGVectorStore (AsyncPGVectorStore) through its create class method implemented in langchain_postgres/v2/async_vectorstore.py.

Specs

I am running my database with docker using pgvector/pgvector:pg17 image.

Python specs :

  • python 3.10.12
  • langchain>=0.3.27
  • langchain-postgres>=0.0.15
  • psycopg[binary]>=3.2.9
  • pgvector<0.4
  • asyncpg>=0.30.0

Issue

If I change "USER-DEFINED" to "vector", it works without any issues.
It looks like a good idea, but as I am not part of the dev team there must be things I am missing.

# langchain_postgres/v2/async_vectorstore.py

class AsyncPGVectorStore(VectorStore):
    # ...

    @classmethod
    async def create(self, ...) -> AsyncPGVectorStore:
        # ...
        
        # sql query columns data from information_schema
        stmt = "SELECT column_name, data_type FROM information_schema.columns WHERE table_name = :table_name AND table_schema = :schema_name"
        async with engine._pool.connect() as conn:
            result = await conn.execute(
                text(stmt),
                {"table_name": table_name, "schema_name": schema_name},
            )
            result_map = result.mappings()
            results = result_map.fetchall()
        columns = {}
        for field in results:
            columns[field["column_name"]] = field["data_type"]  # data_type is "vector" for embedding_column

        # ...

        if columns[embedding_column] != "USER-DEFINED":   # different from information_schema
            raise ValueError(
                f"Embedding column, {embedding_column}, is not type Vector."
            )

        # ...

Thanks for the work put in the library !

Originally created by @NanoClem on GitHub (Aug 6, 2025). Originally assigned to: @averikitsch on GitHub. Hello ! I am trying to use the latest features of `langchain-postgres` as they perfectly answer my need of reusing a pre-existing table. I think I have stumbled upon a bug during the instanciation of PGVectorStore (AsyncPGVectorStore) through its `create` class method implemented in `langchain_postgres/v2/async_vectorstore.py`. # Specs I am running my database with docker using `pgvector/pgvector:pg17` image. Python specs : - python 3.10.12 - langchain>=0.3.27 - langchain-postgres>=0.0.15 - psycopg[binary]>=3.2.9 - pgvector<0.4 - asyncpg>=0.30.0 # Issue If I change "USER-DEFINED" to "vector", it works without any issues. It looks like a good idea, but as I am not part of the dev team there must be things I am missing. ```python # langchain_postgres/v2/async_vectorstore.py class AsyncPGVectorStore(VectorStore): # ... @classmethod async def create(self, ...) -> AsyncPGVectorStore: # ... # sql query columns data from information_schema stmt = "SELECT column_name, data_type FROM information_schema.columns WHERE table_name = :table_name AND table_schema = :schema_name" async with engine._pool.connect() as conn: result = await conn.execute( text(stmt), {"table_name": table_name, "schema_name": schema_name}, ) result_map = result.mappings() results = result_map.fetchall() columns = {} for field in results: columns[field["column_name"]] = field["data_type"] # data_type is "vector" for embedding_column # ... if columns[embedding_column] != "USER-DEFINED": # different from information_schema raise ValueError( f"Embedding column, {embedding_column}, is not type Vector." ) # ... ``` Thanks for the work put in the library !
yindo closed this issue 2026-02-16 05:16:30 -05:00
Author
Owner

@averikitsch commented on GitHub (Aug 8, 2025):

Hi @NanoClem , can you provide the error that you are facing? I am unable to reproduce your issue. When using this container, the underlying code SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'my_table'; returns "USER_DEFINED" not "vector".

@averikitsch commented on GitHub (Aug 8, 2025): Hi @NanoClem , can you provide the error that you are facing? I am unable to reproduce your issue. When using this container, the underlying code `SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'my_table';` returns "USER_DEFINED" not "vector".
Author
Owner

@NanoClem commented on GitHub (Aug 10, 2025):

Sorry, I don't have access to my work PC at the moment. I will recreate a local environnement on my personal machine by tomorrow so I can double check this.

For what it is worth, I created my tables using slqalchemy ORM with alembic migrations. My vector's column type is of Vector (pgvector.sqalchemy), and I saw there was another type VECTOR under the same package. I will investigate this lead once I get home later in the afternoon.

@NanoClem commented on GitHub (Aug 10, 2025): Sorry, I don't have access to my work PC at the moment. I will recreate a local environnement on my personal machine by tomorrow so I can double check this. For what it is worth, I created my tables using slqalchemy ORM with alembic migrations. My vector's column type is of `Vector` (`pgvector.sqalchemy`), and I saw there was another type `VECTOR` under the same package. I will investigate this lead once I get home later in the afternoon.
Author
Owner

@NanoClem commented on GitHub (Aug 10, 2025):

I cannot reproduce the error on my personal machine with a minimal setup. I also get USER-DEFINED whether I use pgvector.sqlalchemy.Vector or pgvector.sqlalchemy.VECTOR class in my sqlalchemy model.

I created a repo when attempting to reproduce the error.

Guess I just have to properly re-create my tables with my alembic revisions in case I did something wrong during my initial setup at work 😓

Anyway, thank you for taking the time to investigate !

@NanoClem commented on GitHub (Aug 10, 2025): I cannot reproduce the error on my personal machine with a minimal setup. I also get `USER-DEFINED` whether I use `pgvector.sqlalchemy.Vector` or `pgvector.sqlalchemy.VECTOR` class in my sqlalchemy model. I created a [repo](https://github.com/NanoClem/pg-vectorstore-boilerplatel) when attempting to reproduce the error. Guess I just have to properly re-create my tables with my alembic revisions in case I did something wrong during my initial setup at work 😓 Anyway, thank you for taking the time to investigate !
Author
Owner

@onestardao commented on GitHub (Aug 11, 2025):

this is a classic ProblemMap No.16 — the type check is being done against the information_schema output instead of the driver’s accepted type list.
pgvector stores the column as USER-DEFINED when using certain vector types, so the strict equality check fails even though the column is valid.

you can confirm by running a manual \d+ in psql — if the column shows the correct dimensions, the failure is purely in the validation branch, not the storage.
short-term fix is to patch the check to accept USER-DEFINED alongside vector, or bypass the clause when the target type matches pgvector.

btw we’ve mapped out 16 such recurring issues (including this one) and have helped 70+ devs fix RAG-related problems under MIT-licensed tooling — ping me if you want the full list.

@onestardao commented on GitHub (Aug 11, 2025): this is a classic ProblemMap No.16 — the type check is being done against the information_schema output instead of the driver’s accepted type list. pgvector stores the column as USER-DEFINED when using certain vector types, so the strict equality check fails even though the column is valid. you can confirm by running a manual \d+ <table> in psql — if the column shows the correct dimensions, the failure is purely in the validation branch, not the storage. short-term fix is to patch the check to accept USER-DEFINED alongside vector, or bypass the clause when the target type matches pgvector. btw we’ve mapped out 16 such recurring issues (including this one) and have helped 70+ devs fix RAG-related problems under MIT-licensed tooling — ping me if you want the full list.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langchain-ai/langchain-postgres#88