[feat]allow user to specify collection & embedding table names

[liunux4odoo]

allow user to specify collection & embedding table names, so user can create multiple vector store pairs for different usage.
also some small fix:

• remove type annotaion for EmbeddingStore.embedding
• give default values for connection_string_from_db_params
• fix bug in _results_to_docs_and_scores and other similar methods

example code:

# running environment:
# python = 3.10.12
# pgvector = 0.2.5
# sqlalchemy = 2.0.31


from langchain_postgres import PGVector
from langchain_openai import OpenAIEmbeddings


embedding = OpenAIEmbeddings(base_url="http://xxx/v1",
                     api_key="sk-", model="xx")
con = PGVector.connection_string_from_db_params("langchain")
vs = PGVector.from_texts(['hello world'], embedding , collection_name="test", connection=con,
                         collection_table_name="collection", embedding_table_name="embedding")
docs = vs.similarity_search("hello there")
print(docs)

[IanQS]

Thank you for this PR! Unrelated-ish, I guess(?) but what's the difference between a collection and a table? I tried looking it up but everything I found pointed me towards mongodb and their concept of a collection

[liunux4odoo]

Thank you for this PR! Unrelated-ish, I guess(?) but what's the difference between a collection and a table? I tried looking it up but everything I found pointed me towards mongodb and their concept of a collection

In langchain-postgres all vectors are stored in one table named langchain_pg_embedding, there is a column named collection_id to distinguish different vector stores.

[IanQS]

Got it! Thank you. Can you describe why we might need separate collections when we have separate tables? What's the use-case there then? In a traditional DB we would just have separate tables, no?

[liunux4odoo]

ctions when we have separate tables? What's the use-case there then? In a traditional DB we would just have separate tables, no?

Currently we have separate collections for every vector store in one table, it's convenient to do search across collections (although it does not support this yet).
Sometimes we want to group other collections in another table for different purpose, this is what this PR does.

[andreped]

@IanQS This would be of interest to us as well as we would like to have different tables when testing stuff in DEV, without introducing a completely new PostgreSQL DB instance or impacting others working against the same DEV database.