Support for variable-length input arrays

[pjungwir]

Support for variable-length input arrays

[pjungwir]

Hmm, I don't love adding a parameter here for that, and then having to maintain two versions of each function. At the least I'd rather use a different name (e.g. varvec_to_sum) so that we can still add new parameters for something else someday. But before that, how about we write a helper function that expands an input array by padding it will NULLs so that it is some fixed length? So you could do SELECT vec_to_sum(pad_vec(array_column, 8)). It would be an error to give pad_vec an array longer than the passed in integer.

That won't be as fast as your proposal, but I'd like to try it out and see if it's fast enough. I don't think it will be very expensive.

I'm happy to do the work on that one. Perhaps this weekend if I get the chance.

[msqr]

Ah, the padding function sounds interesting, thanks! Given I expect most rows to have the same size, would it work out that the function could simply return the input array without having to make a copy? That sounds pretty great, if so.

[pjungwir]

I don't think that would cause any problems. Seems like a nice optimization!

…

On Fri, Nov 26, 2021 at 12:40 PM Matt Magoffin ***@***.***> wrote: Ah, the padding function sounds interesting, thanks! Given I expect most rows to have the same size, would it work out that the function could simply return the input array without having to make a copy? That sounds pretty great, if so. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFBHAJ6MZAMDZFMUWVGKGTUN7WFBANCNFSM5IZR72RA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[pjungwir]

Okay I added this function on a pad_vec branch.

Adding new functions is awkward, especially when collaborating, because they need to go into a new aggs_for_vecs--some-new-version.sql file, but you don't want to make that file in every change and then get merge conflicts. I made a rel-1.3.0 branch that has a copy of it. I think I'll merge that into master and then we can rebase things off that (e.g. this function).

[msqr]

This is great, thank you! I've pulled in your changes to my feature/numeric2 branch; it merged in fine, all tests pass, and I can play around with it.

[msqr]

I've been testing the new pad_vec function works perfectly for this use case. Thanks for the quick turnaround on that.