Multiple schemas via request's path /schema1/tableA, /schema2/viewB

[steve-chavez]

If we really want to make working with multiple schemas easy, we should reconsider just doing that via the request's path, like /schema1/tableA, /schema2/viewB etc.

Originally posted by @wolfgangwalther in #2927 (comment)

[steve-chavez]

Copy pasting the discussion on #2927

---

like /schema1/tableA, /schema2/viewB

@steve-chavez I'd be against it because:

• it makes the url brittle (a schema is an implementation detail and a rename would break the url)
• would make impossible to do resource embedding across different schemas (if we ever want to)
• will make custom urls harder to implement later on (Customize URL structure - Confusion about /rpc/ prefix, move stored procedures to root level #1086 (comment))

---

it makes the url brittle (a schema is an implementation detail and a rename would break the url)

@wolfgangwalther That's not true. A schema is not an implementation detail as soon as you use multiple of them. Right now, you need to pass the schema in the -Profile headers. That makes it part of the API.

Whether to change a header or the path in the URL if you change the schema name - does not make a difference. You need to change it anyway.

would make impossible to do resource embedding across different schemas (if we ever want to)

Not true, either. You just need syntax. you could do /schema1/table1?select=*,schema2/table2(*), for example. That's actually quite natural and much easier to deal with name conflicts compared to the header approach.

will make custom urls harder to implement later on

And of course I don't agree here as well. If done right, this could actually be a step towards custom URLs.

[steve-chavez]

@wolfgangwalther Just had an idea for implementing this on #2157 (comment). I think that's the way forward, seems pretty simple and plays along with #1086 (comment).

Will close here.