community[patch]: Adds support for passing schemaName to pgvector

[ZuesYousif]

Adds schemaName option to PGVectorStoreArgs
Adds extensionSchemaName option to PGVectorStoreArgs

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
langchainjs-api-refs	🛑 Canceled (Inspect)			Feb 29, 2024 2:28am
langchainjs-docs	🛑 Canceled (Inspect)			Feb 29, 2024 2:28am

[jacoblee93]

Don't forget to run yarn format!

[jacoblee93]

Should these be in quotes to account for capitalization?

[jacoblee93]

Looks good to me overall - main question is should these new/old queries be in quotes though to account for capitalizations?

[ZuesYousif]

Looks good to me overall - main question is should these new/old queries be in quotes though to account for capitalizations?

Good catch there, I've added some string wrapping around a few calls where it seems appropriate

[ZuesYousif]

I found a bug where the operator <=> from pgvector was out of scope when pgvector is nested under a schema. To fix this I pushed a small change that sets the schema in a query prior to using the operator. I tried passing it under the same pool.query call however it said only one query is allowed & after testing the changes under a it's own call it seems to be working now.

[MJDeligan]

Does setting the search_path only persist for that specific connection or does it change at the db level?

[ZuesYousif]

Does setting the search_path only persist for that specific connection or does it change at the db level?

It looks like it only lasts for the duration of that connection. When I manually query the db with SELECT CURRENT_SCHEMA, CURRENT_SCHEMA(); after running this the db still returns public

[MJDeligan]

Gotcha! Is that for the pool in general or is this tied to the client the pool creates to run the query? In the first case, we may run into issues if we ever allow passing a pool instance, instead of creating a new one (as proposed in #4409 and present in PostgresChatHistory) among other unforeseen consequences for users. In the latter case, we could get unlucky and the pool uses a different client for each query. Have you seen this ? Might be applicable here?.

[ZuesYousif]

Gotcha! Is that for the pool in general or is this tied to the client the pool creates to run the query? In the first case, we may run into issues if we ever allow passing a pool instance, instead of creating a new one (as proposed in #4409 and present in PostgresChatHistory) among other unforeseen consequences for users. In the latter case, we could get unlucky and the pool uses a different client for each query. Have you seen this ? Might be applicable here?.

I haven't seen that yet, thanks that helps a lot in this case. I pushed a refactor that opts for the OPERATOR function instead which seems to fix the initial scope bug.

[jacoblee93]

Thank you both!