RPC text/javascript result Content-Type question

[mkleczek]

Hi,

I would like to return a js module code from my RPC function:

CREATE DOMAIN "text/javascript" AS text;
CREATE OR REPLACE FUNCTION module.js() RETURNS "text/javascript" ...

The module is loaded from html:

<script type="module" src="uri_to_module_js"></script>

It looks like PostgREST (12.0.2) response has content type header set to "application/json" (and not "text/javascript"). Accept header sent by the browser is */*.

I tried to find a solution and there is a discussion about setting "pgrst.accept" on the function - is this necessary? And if that's so - what should be its value?

[wolfgangwalther]

I tried to find a solution and there is a discussion about setting "pgrst.accept" on the function - is this necessary? And if that's so - what should be its value?

No, that was only an idea, but not implemented like that. Instead we now have the DOMAINs you are using.

I just looked into one of the functions where I use this, and it seems I am still doing this:

  SELECT set_config('response.headers', '[{"Content-Type": "text/css"}]', true);

Even though the function RETURNS "text/css". I would expect this to work without setting the Content-Type header manually, but maybe it doesn't.

[mkleczek]

Well... I does work for my other function:

CREATE DOMAIN "text/html" AS text;
CREATE OR REPLACE FUNCTION "index.html"() AS "text/html" ...

But in this case the browser is sending proper Accept header (containing text/html in the list). I guest that might be a problem with the way how PostgREST is handling Accept = */*.

Do you think it is worth creating an issue?

[wolfgangwalther]

Do you think it is worth creating an issue?

I think so, yes. Not sure whether that was by design, intentionally left out for now - or a bug, though.

[mkleczek]

Actually created two separate issues:
#3391
and
#3392

[steve-chavez]

If the browser sends */*, you need to use the any handler. Otherwise postgREST will use the default application/json handler (which does json_agg underlyingly). You'll manually have to set the "text/javascript" with set_config('response.headers'.

This is a limitation of the design of custom media type handlers. There are more flexible alternatives (like #3037), which could come in the future. For now you'll have to use the any handler workaround.

[steve-chavez]

@mkleczek Closed your above issues linking to this answer, hope that doesn't come as rude.

[wolfgangwalther]

I re-opened one of them, because I still think this is a bug. The other one is essentially a duplicate, so kept closed.

[mkleczek]

Actually that's what I ended up using (I mean any handler). Missed it in the documentation though so maybe it would be worth having some more use case oriented navigation - not sure though.

Anyway - thanks for the answer - will try to analyse the issues with current media type handlers design and maybe I can come up with some ideas.