@ChuckHend Have a look at your free time and kindly approve workflows, if any adjustments needed i am happy to incorporate them

Waiting for a quick review on this too - @ChuckHend

@ChuckHend Any changes needed here?

I might need to provide further clarification in the issue. What is intended is that when calling vectorize.table() on an existing table, each row is split into multiple 'chunks' (one new row for each chunk). I think these new rows will need to live on a separate table.

@ChuckHend Updated the changes with intended approach of chunking vectorie.table by retreiving rows and lives into new table,

Have a review on it and If any changes or modifications required I am ready to incorporate them

@ChuckHend Have a review on it in your free time

Can you add a test or two that shows how the functionality will work and assert that it functions as expected?

Sure! I will update the tests

Yes, let's leave the integration with vectorize.table() out to make this simpler / easier. Just keep chunk_text() a sql function that we can call directly, and add a couple tests that validate its functionality and shows how to use it.

Okay!

@ChuckHend Any reviews on it

Ill have this reviewed by end of week

I haven't pushed my latest changes here which are in my local :)

@ChuckHend 👋
I have updated the chunk_text function to use the text_splitter crate instead of the previous manual approach. This change makes the chunking more accurate especially for larger documents and ensures we preserve word boundaries while still enforcing a character limit. The previous logic sometimes caused inconsistencies with expected vs actual outputs. Using text_splitter brings more stability and aligns with the best practices seen in LangChain’s recursive text splitter. I have also updated docs of it's usage as standalone sql function and added couple of tests that validate its functionality and tests passes locally.

test test_chunk_text ... URL: ***localhost:28817/postgres
ok

With this I think it's ready to merge