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 по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: error context for vacuum to include block number
Следующее
От: "Moon, Insung"
Дата:
Сообщение: Flexible pglz_stategy values and delete const.