Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent output for a function call from postgrest API url #1834

Closed
alan-francis opened this issue Apr 28, 2021 · 3 comments
Closed

Inconsistent output for a function call from postgrest API url #1834

alan-francis opened this issue Apr 28, 2021 · 3 comments
Labels

Comments

@alan-francis
Copy link

Hi
while calling a function from my postgrest api url I am getting the result with the column name like below.

URL : http://localhost:16000/rpc/fn_name?terms=patents

Result:

[{
"fn_name":[
    1,
    [
      "Patents"
    ],
    null,
    [
      [
        "Patents: Patents"
      ]
    ]
  ]
}] 

But after I restart my postgrest docker my result changes to the one below without the function name.

[
  1,
  [
    "Patents"
  ],
  null,
  [
    [
      "Patents: Patents"
    ]
  ]
]

My desired out put is the one without the function name. But I don't know why this inconsistency in the output from postgrest. I tried sending the server a SIGUSR1 signal and also schema reloading.

@wolfgangwalther
Copy link
Member

If restarting the server helps, but sending a signal or "reload the schema" does not - then you're doing something wrong on the latter. Restarting the server reloads the schema, too.

Which version of PostgREST are you using?

@alan-francis
Copy link
Author

alan-francis commented Apr 28, 2021

Thanks for the reply. The postgREST version we are using is v7.0.1. First of all, I am not sure which one is the correct output. Once the postgrest is up and running, and I create a function and call it from the API, I am getting the result as an array of object with the function name as the object key. If I restart the postgrest docker, which should reload the schema as well, I am getting the result without the function name (which means the value of the previous results' object key). As i would be doing my db schema, view, function creation dynamically, the results are not consistent as it depends on whether my docker is restarted before the schema/view/function generation. I hope my issue is more clear now.

@wolfgangwalther
Copy link
Member

Thanks for the reply. The postgREST version we are using is v7.0.1. First of all, I am not sure which one is the correct output.

The output without the function name is correct. In v7.0.1 this didn't work for all functions, depending on the returned type. We have since cleaned this up a bit and the output should be more consistent in the latest nightly. However, I don't think this is something you are experiencing, because your output is correct once the schema cache is reloaded.

We need an uptodate schema cache to be able to tell which return type a function has and then properly format it. There is no way around that.

Once the postgrest is up and running, and I create a function and call it from the API, I am getting the result as an array of object with the function name as the object key. If I restart the postgrest docker, which should reload the schema as well, I am getting the result without the function name (which means the value of the previous results' object key).

That's all expected.

As i would be doing my db schema, view, function creation dynamically, the results are not consistent as it depends on whether my docker is restarted before the schema/view/function generation. I hope my issue is more clear now.

In our latest nightly we have added the ability to reload the schema cache via postgres' NOTIFY. You can use this to create an event trigger to automatically reload the schema after a change. See here for an example: #1512 (comment)

@PostgREST PostgREST locked and limited conversation to collaborators Apr 28, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
Development

No branches or pull requests

2 participants