feat: support POST

[soedirgo]

What kind of change does this PR introduce?

Feature

What is the new behavior?

Support POST requests via net.http_post(). Right now the function is mostly copypasting from http_get(), but I think in the future this should be refactored to use a (public?) generic function net.http().

@olirice the order of arguments to net.http_post() is a bit out of place since required arguments have to be listed first - let me know if you want them changed. Also I see I'm failing the pytest stuff - anything I should look at? Do you want me to add a test as well? (haven't looked at how it's setup)

@steve-chavez CMIIW, we currently ignore params and headers in the request right? Atm content_type is handled separately, but I think we should handle it together with headers. In retrospect, I probably should've omitted content_type in the SQL too... (was following pgsql-http) Also, let me know if I've freed the palloc'd stuff properly.

Additional context

Closes #6.

TODOs

• merge Content-Type into headers
• convert body to byte array to align with Look into body response as bytea #5
• http_post fails when body is null
• check memory leak

[olirice]

@soedirgo the background worker crashes while running test suite

[steve-chavez]

CMIIW, we currently ignore params and headers in the request right? Atm content_type is handled separately, but I think we should handle it together with headers

@soedirgo Yeah, both ignored. Also agree with the content-type change, Oli has opened an issue for tracking that #23.

[soedirgo]

Both POST and headers should be supported now. As for the remaining issues, they can be handled here or in a separate PR:

• POST with body null fails despite null checking. Something similar happens when using null body for GET (which is legal HTTP, to my dismay) non-issue, this is because the functions are defined with strict. Is this intended @olirice? Setting e.g. headers to null shouldn't abort the function IMO (though empty jsonb works just as well)
• memory leak (labeled FIXME), I also suspect we may have other leaks given how many pfrees there are in pgsql-http (even for datum deserializations): https://github.com/pramsey/pgsql-http/blob/1e430f5869234e0c60625eb15a4f7c166cae1abe/http.c#L1006-L1009

[steve-chavez]

non-issue, this is because the functions are defined with strict

Functions with strict are bad for performance, as noted in this postgrest issue. I think that should be removed.

memory leak (labeled FIXME), I also suspect we may have other leaks given how many pfrees there are in pgsql-http (even for datum deserializations)

Yeah, true. Ideally we'd integrate valgrind and also run it on CI.