"postgres query error" when using subscriptions and "_st_d_within" expression to compare columns of type geography
See original GitHub issueI tested postgis extension and _st_d_within
expressions and noticed following bug.
First of all I have a table called messages and one of the columns is called location (type geography). I created following query:
query GetMessages($point: geography!, $distance: Float!) {
messages(where: {location: {_st_d_within: {distance: $distance, from: $point}}}) {
id
location
message
createdAt
}
}
and used following variables:
{
"point": {
"type": "Point",
"coordinates": [ 52.2, 40.2 ]
},
"distance": 20.0
}
Everything works as expected, I get messages within the radius defined in variables.
If I change the same query to subscription:
subscription GetMessages($point: geography!, $distance: Float!) {
messages(where: {location: {_st_d_within: {distance: $distance, from: $point}}}) {
id
location
message
createdAt
}
}
and use same variables I get following error on graphiql:
{
"data": null,
"errors": [
{
"errors": [
{
"extensions": {
"path": "$",
"code": "unexpected"
},
"message": "postgres query error"
}
]
}
]
}
I also checked out the postgres logs and found out following error message:
postgres_1 | 2019-10-25 17:47:04.581 UTC [4773] ERROR: parse error - invalid geometry
postgres_1 | 2019-10-25 17:47:04.581 UTC [4773] HINT: "{"" <-- parse error at position 2 within geometry
postgres_1 | 2019-10-25 17:47:04.581 UTC [4773] STATEMENT:
postgres_1 | select
postgres_1 | _subs.result_id, _fld_resp.root as result
postgres_1 | from
postgres_1 | unnest(
postgres_1 | $1::uuid[], $2::json[]
postgres_1 | ) _subs (result_id, result_vars)
postgres_1 | left outer join lateral
postgres_1 | (
postgres_1 | SELECT coalesce(json_agg("root" ), '[]' ) AS "root" FROM (SELECT row_to_json((SELECT "_4_e" FROM (SELECT "_0_root.base"."id" AS "id", (ST_AsGeoJSON("_0_root.base"."location", 15, 4 ))::json AS "location", "_0_root.base"."message" AS "message", "_0_root.base"."createdAt" AS "createdAt", "_3_root.ar.root.comments_aggregate"."comments_aggregate" AS "comments_aggregate" ) AS "_4_e" ) ) AS "root" FROM (SELECT * FROM "public"."messages" WHERE ((ST_DWithin("public"."messages"."location", (("_subs"."result_vars"#>>ARRAY['query', 'point']))::geography, (("_subs"."result_vars"#>>ARRAY['query', 'distance']))::real, (("_subs"."result_vars"#>>ARRAY['synthetic', '0']))::boolean ))) ) AS "_0_root.base" LEFT OUTER JOIN LATERAL (SELECT json_build_object('aggregate', json_build_object('count', COUNT(*) ) ) AS "comments_aggregate" FROM (SELECT 1 AS "root.ar.root.comments_aggregate__one" FROM (SELECT * FROM "public"."comment" WHERE (("_0_root.base"."id") = ("messageId")) ) AS "_1_root.ar.root.comments_aggregate.base" ) AS "_2_root.ar.root.comments_aggregate" ) AS "_3_root.ar.root.comments_aggregate" ON ('true') ) AS "_5_root"
postgres_1 | ) _fld_resp ON ('true')
Seems like when using the subscription some kind of parse error is happening.
I also started a discussion about this recently on Discord and another user confirmed the same issue.
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (2 by maintainers)
Top Results From Across the Web
ST_DWithin query throwing 42601 error? - GIS Stack Exchange
When using ST_DWithin one needs to compare data which have the same SRID. So, if column osm_point.way has a different SRID (you said...
Read more >ERROR: function st_dwithin(geometry, double precision ...
ST_DWithin checks if two geometries are within a given distance of each others. It takes 2 geometries and a distance as parameters.
Read more >Geography functions | BigQuery - Google Cloud
NOTE: A GEOGRAPHY does not contain its own boundary. Compare with ST_COVERS . Return type. BOOL. Example. The following query tests whether the...
Read more >#4739 (st_dwithin : no spatial operator found) – PostGIS
This is present in the current master branch too. I've had a quick look and I don't see how the PG system cache...
Read more >Documentation: 8.2: Basic Statements - PostgreSQL
If the expression's result data type doesn't match the variable's data type, ... or column name that you need to reference in queries...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
PR #3344 fixes this, but it still needs a couple final touches before merging, which is why it has not been merged yet. I would very much like to make those final touches, but neither I nor anyone else on the team have been able to get to it yet.
It is on our backlog, so I assure we have not forgotten about it! But if anyone is interested in getting the fix in faster, by all means, feel free to pick up from where #3344 left off (and I can give pointers to anyone interested).
Hello, is there any news?