Re: 1 Status of vertical clustered index - 2 Join using(fk_constraint) suggestion - 3 Status of pgsql's parser autonomization
От | maxzor |
---|---|
Тема | Re: 1 Status of vertical clustered index - 2 Join using(fk_constraint) suggestion - 3 Status of pgsql's parser autonomization |
Дата | |
Msg-id | 8f242571-20f7-5b9f-d037-dd0d0668a80a@maxzor.eu обсуждение исходный текст |
Ответ на | Re: 1 Status of vertical clustered index - 2 Join using(fk_constraint) suggestion - 3 Status of pgsql's parser autonomization (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Список | pgsql-hackers |
> ... Thank you will look into it! > I'm not really sure what's the point / benefit here. Initially it seemed > you simply propose a syntax saying "do a join using the columns in the > FK constraint" but it's unclear to me how this implies any writing > speedup? This is exactly what I mean. If you know the fk_constraint (usually there are simple patterns) you are all set, or else... you could use a function fk(t, t2) to lookup pg_constraint, or even better / more bloat, have psql do autocompletion for you? Corner case multiple fks between t and t2. 'from t join t2 using(fk(t,t2))' > I have no idea what you mean by "less coupled" here. What are the > requirements / use cases you're thinking about? A lot of external tools do query parsing or validation, I wish they could use the official parser as a dependency. AFAIK it is currently not the case and everyone is re-implementing its subpar parser. > FWIW I think it's pretty bad idea to post questions about three very > different topics into a single pgsql-hackers thread. That'll just lead > to a lot of confusion. Right... I figured as a newcomer I would not spam the mailing list. Best regards
В списке pgsql-hackers по дате отправления: