feat: WIP allow spread operators in to-many relationships

[laurenceisla]

WIP on #3041

[laurenceisla]

My approach right now is to generate this query for a to-many request:

curl 'localhost:3000/clients?select=name,...projects(name,id)'

SELECT "test"."clients"."name",
       "clients_projects_1"."name",
       "clients_projects_1"."id"
FROM "test"."clients"
LEFT JOIN LATERAL (
  SELECT json_agg("projects_1"."name") AS "name",
         json_agg("projects_1"."id") AS "id"
  FROM "test"."projects" AS "projects_1"
  WHERE "projects_1"."client_id" = "test"."clients"."id"
) AS "clients_projects_1" ON TRUE

Right now this gives the expected result. But aggregates are not working correctly, because they are designed to be selected in the top query with a GROUP BY. A solution would be to not do the json_agg() inside the sub-query and do it in the top one and treat it as another aggregate (with GROUP BY). Like this:

SELECT "test"."clients"."name",
      json_agg("clients_projects_1"."name") AS "name",
      json_agg("clients_projects_1"."id") AS "id"
FROM "test"."clients"
LEFT JOIN LATERAL (
  SELECT "projects_1"."name",
         "projects_1"."id"
  FROM "test"."projects" AS "projects_1"
  WHERE "projects_1"."client_id" = "test"."clients"."id"
) AS "clients_projects_1" ON TRUE
GROUP BY "test"."clients"."name"

Not sure which one is better/easier right now... I'm thinking the latter.

[laurenceisla]

I think that, instead of forbidding *, it would be better to expand the selection using the column names from the Schema Cache. In the same way as aggregates do it here:

postgrest/src/PostgREST/Plan.hs

Lines 410 to 414 in c3070bb

	-- | Expand "select *" into explicit field names of the table in the following situations:
	-- * When there are data representations present.
	-- * When there is an aggregate function in a given ReadPlan or its parent.
	expandStars :: ResolverContext -> ReadPlanTree -> Either ApiRequestError ReadPlanTree
	expandStars ctx rPlanTree = Right $ expandStarsForReadPlan False rPlanTree

[wolfgangwalther]

Right now this gives the expected result. But aggregates are not working correctly, because they are designed to be selected in the top query with a GROUP BY. A solution would be to not do the json_agg() inside the sub-query and do it in the top one and treat it as another aggregate (with GROUP BY).

Having the json_agg in the outer query would make the query cleaner, imho.