Hi, I found that postgraphql doesn't support overloading functions,the minimal reproduce case is
create schema test_a;
create function test_a.overloading_function(text) returns integer as $$
select 1 + 1
$$ language sql;
create function test_a.overloading_function(text, text) returns integer as $$
select 1 + 2
$$ language sql
Please inform me if I had missed that in document, or would you consider to put it on schedule?
An easy temporary workaround for this is to define aliases for these functions; e.g.
create function test_a.overloading_function__text(a text) returns integer as $$
select test_a.overloading_function(a)
$$ language sql;
create function test_a.overloading_function__text__text(a text, b text) returns integer as $$
select test_a.overloading_function(a, b)
$$ language sql;
My knowledge of GraphQL is still extremely superficial, but I think because of the type signatures in GraphQL (where each argument is named and typed) we can't represent overloaded functions that take different types as would be the case for generic overloaded functions. So if we were to support this internally we'd have to derive function names (like those in my example above) for the different overloadings. Then we'd have a challenge as to how to make these predictable, non-confusing and worst of all persistent. e.g. if we started with the two argument version test_a.overloading_function which we'd just call overloadingFunction when you add the second function which takes just one argument it would trigger the "overloading" logic and both functions would rename which would break backwards compatibility.
Do you have thoughts on how we might solve this @lcjnil?
@benjie Thanks for your reply!
Your workaround does a good idea, but still hard to use. More to say, I am trying to wrapper a function to support both jwt.claims.* as well as token which is used in token-based authtication (not jwt), perhaps overloading function is the easiest way to do that, or I need to write wrappers like you.
Though, my knowledge to graphql is quite naive, and I can't figure out a way to resolve it, but I do think your workaround should be placed in document.
Thanks again.
I’m going to re-open this, because I do feel like it’s a space we can explore. I haven’t looked into this too much, but I get the feeling that if we have named arguments we may be able to intelligently create a GraphQL field for overloaded functions. It’s not a high priority though, so aliases are probably your best bet for now like @benjie suggests :blush:
Hi ,
I would like to know if at this moment overloading functions are supported .It would really help me in my project .
Thank you .
There has been no change on this front.
If I may , I have one more question .I am trying to use plv8 , to write
functions in Postgres , to be queried by Postgraphql .
When giving it complex arguments , as array of objects , it does not work
at all .
For example I get "message": "ReferenceError: sort_By is not defined", even
if I send him a sortBy parameter .
I am trying actually to build function that replaces the default orderBy
because I need to have only one function that does search and order on the
server , to be used with a grid .
Can you kindly tell me what am I doing wrong ?
Thank you ...
create or replace function sortAndOrder(start int, page int, filter_By
filter_By[], sort_By order_By[]) returns setof abc.relations as
$$
plv8.elog(NOTICE, sort_By);
if (typeof filter_By == "undefined") {
var sort = [{field: "naam"}];
if (typeof sort_By == "undefined") {
var query = "select * from abc.relations ORDER BY naam DESC limit "
return a;}
}
$$
language plv8 stable;
create or replace function sortAndOrder(start int, page int, filter_By
filter_By[], sort_By order_By[]) returns setof abc.relations as
$$
plv8.elog(NOTICE, sort_By);
if (typeof filter_By == "undefined") {
var sort = [{field: "naam"}];
if (typeof sort_By != "undefined") {
var query = "select * from abc.relations ORDER BY ' +
sortBy[0].field +" DESC limit " + start + "OFFSET "+ page ;
var a = plv8.execute(query);
return a;}
}
$$
language plv8 stable
"message": "ReferenceError: sort_By is not defined",
On Mon, Jan 29, 2018 at 10:22 AM, Benjie Gillam notifications@github.com
wrote:
There has been no change on this front.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/postgraphql/postgraphql/issues/284#issuecomment-361171263,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AgsnU8vkmamisYndYdq4_6RkjkXSBQ74ks5tPX_CgaJpZM4LQlWt
.
SQL is case insensitive, you've not wrapped your identifiers in quotes so when they come through to plv8 they will be seen as filter_by, not filter_By.
Please write further issues into GitHub directly and wrap your code snippets in triple backticks to make them more legible - reading the formatting from email is a nuisance.
I'm going to close this for now; but if overloaded functions are an issue for you I'd love for you to get in touch - either here, via email, twitter, or Gitter - so I can understand exactly what your functions do and how you feel they should be exposed.
Most helpful comment
I’m going to re-open this, because I do feel like it’s a space we can explore. I haven’t looked into this too much, but I get the feeling that if we have named arguments we may be able to intelligently create a GraphQL field for overloaded functions. It’s not a high priority though, so aliases are probably your best bet for now like @benjie suggests :blush: