Support setting `Prefer: params=single-object` when making `.rpc()` call

[dshukertjr]

Feature request

Is your feature request related to a problem? Please describe.

When calling a Postgres function via .rpc() method, you can pass Prefer: params=single-object header to be able to pass JSON object as the parameter. Was wondering if this is something we want to support.
https://postgrest.org/en/v9.0/api.html#calling-functions-with-a-single-json-parameter

Describe the solution you'd like

Add a flag or something to .rpc() maybe? Something like this:

.rpc('my_function', {
  name: 'Michael'
}, { singleObject: true })

Describe alternatives you've considered

A developer can create a regular Postgres function with named parameters.

Additional context

This feature was requested on the Dart library, and wanted to bring the discussion over to the JS library.
supabase/supabase-flutter#197

[dsyrstad]

Please also add: Prefer: params=multiple-objects https://postgrest.org/en/stable/api.html#bulk-call. However, this will require accepting an array of objects rather than just an object - kind of like insert.

[steve-chavez]

@dsyrstad Could you instead use an array parameter for your function? params=multiple-objects doesn't have good performance and we thought it'd be better to not expose it to the clients. Likely it will be deprecated/removed from PostgREST as well.

[dsyrstad]

@dsyrstad Could you instead use an array parameter for your function? params=multiple-objects doesn't have good performance and we thought it'd be better to not expose it to the clients.

@steve-chavez I am only using Prefer: params=single-object right now. I just thought for completeness we would include params=multiple-objects, but I'm not using it. I'm okay with leaving it out.

[soedirgo]

Curious, is there any downside to just using a single unnamed parameter?

PostgREST will do the right thing without needing params=single-object - other than needing to use $1 instead of names in the function definition, I'm not sure of what value params=single-object gives.

[dsyrstad]

Curious, is there any downside to just using a single unnamed parameter?

PostgREST will do the right thing without needing params=single-object - other than needing to use $1 instead of names in the function definition, I'm not sure of what value params=single-object gives.

@soedirgo Well, it seems that using the unnamed param method would require adding a Content-Type: application/json header, as described in the doc. So it just seems to be a trade-off in headers.

I'm not sure what the resistance is to adding client SDK support for a header that is documented? I already have a workaround which does not require me to change the PG function. I'm looking for a built-in in solution that does not require a workaround.

[soedirgo]

We already supply Content-Type: application/json by default, so that shouldn't be an issue.

Not all features supported upstream should be supported by the client lib - see also params=multiple-objects above.

[dshukertjr]

@soedirgo Should we include a note about single unnamed parameter in the rpc section of the docs maybe?

[dsyrstad]

Maybe we just need the ability to easily add arbitrary headers to the request. I know this is possible currently (not in the Dart SDK 1.0.0 though), but it is cumbersome.

[dshukertjr]

@dsyrstad Unfortunately exposing headers as public member on Dart SDK was more of a mistake than a feature, so it will not be reintroduced unless something similar is added to js client. Is there any reason why single unnamed parameter will not work for your case?

[dsyrstad]

@dsyrstad Unfortunately exposing headers as public member on Dart SDK was more of a mistake than a feature, so it will not be reintroduced unless something similar is added to js client. Is there any reason why single unnamed parameter will not work for your case?

I could use an unnamed parameter with $1 and that ugliness. Before I'll do that, I'll just implement the extension workaround mentioned here: supabase/supabase-flutter#179 (comment).

But again, Postgrest supports a named JSON parameter in a POST request and the client SDK seems to be missing the corresponding functionality.

Also, another person (@CodingSoot) had a use case for an arbitrary (non-Postgrest) header: supabase/supabase-flutter#179 (comment). I think if a couple of people have the requirement, why not support it instead of making the users of the SDK jump through hoops? We've probably spent more time talking about it than it would take to do it.

[soedirgo]

How about a method setHeader(name: string, value: string) on PostgrestTransformBuilder so you can set headers on each request? Willing to accept if you have a PR for it.

[dsyrstad]

That sounds good, as long as we can retrieve a header as well. The Prefer header can be multi-valued, so you need to be able to tell if there's an existing value and concatenate on to it. The client does this internally right now. Also, it looks like the headers are owned by PostgrestBuilder, so the method may need to go there.

If I do a PR, it will probably be on the Dart code base.

[kylerummens]

Any update to this? There doesn't seem to be documentation for single unnamed parameter