Feat/impersonate user

[egor-romanov]

What kind of change does this PR introduce?

• add impersonate user draft

[olirice]

I'm hesitant on this one because its supabase specific and (so far) the goal of this project was to provide a vector-db client-like experience for any postgres instance pgvector.

some other options for apis might be

with vecs.create_client(DB_CONNECTION, {}) as vx: # where {} is a generic settings group
    # do something

or in the short term we could document

with docs.client.Session() as sess:
    sess.execute(...) # settings go here
    docs .... # operations go here

(I think) that'll work on SQLA 2.0 since begin_nested is now automatic

[egor-romanov]

I'm hesitant on this one because its supabase specific and (so far) the goal of this project was to provide a vector-db client-like experience for any postgres instance pgvector.

I am thinking if we can somehow make it as an extension instead. So that it will be easy to use with RLS (as it seems to be a thing people looking for).

Even right now it doesn't break anything, but of course auth.uid() and all request.jwt.claim are very specific to Supabase.

What if we can add this the similar way it is done for adapters? But i think it should have some good generic placement in the call pipeline

[olirice]

similar way it is done for adapters

that could work. would you be able to spec out what you had in mind as an issue?

[olirice]

closing for now