feat: allow aliases in spread embeddings

[laurenceisla]

Allows embedding the same resource multiple times without returning an error:

curl 'localhost:3000/table?select=...e1:embed(name),...e2:embed(name)'

Otherwise, without the aliases, it would return an error (the current implementation).

As mentioned here: #3640 (comment), this is going to be more commonly used in to-many spreads.

[steve-chavez]

Otherwise, without the aliases, it would return an error (the current implementation).

What's the error message?

As mentioned here: #3640 (comment), this is going to be more commonly used in to-many spreads.

Yeah, I haven't seen a use case for to-one spreads.

[laurenceisla]

What's the error message?

This issue mentions it better #2529. It returns the same error here.

[steve-chavez]

#2529 it's a bit different. For spreads the name of the alias is essentially ignored, it doesn't show in the output:

curl 'localhost:3000/table?select=...ignored:embed(name),...ignored:embed(name)'

So if this is a problem, I think the alias should be added automatically somehow. And we shouldn't allow aliases on spreads, since it doesn't make sense for the user. It's an implementation detail.

[laurenceisla]

And we shouldn't allow aliases on spreads,

Ah I just remembered, this is still useful if we want to use filters with one of the relationships. Otherwise it wouldn't be possible to know which one to filter.

[laurenceisla]

Otherwise it wouldn't be possible to know which one to filter.

To give an example, something like this could be possible:

curl 'localhost:3000/factories?select=...p1:processes(batch_count:count()),...p2:processes(total_count:count())&p1.category_id=eq.1'

[steve-chavez]

To give an example, something like this could be possible:

For filtering it does make sense.

Maybe for another issue, I just found the following error:

curl 'localhost:3000/projects?select=*,...clients()'
{"code":"42601","details":null,"hint":null,"message":"syntax error at or near \"FROM\""}