Re: partial JOIN (was: ID column naming convention)

Поиск
Список
Период
Сортировка
От Rafal Pietrak
Тема Re: partial JOIN (was: ID column naming convention)
Дата
Msg-id 562DDC4C.8000909@ztk-rp.eu
обсуждение исходный текст
Ответ на Re: partial JOIN (was: ID column naming convention)  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-general

W dniu 26.10.2015 o 01:49, Jim Nasby pisze:
> On 10/25/15 2:30 AM, Rafal Pietrak wrote:
[----------------]
> But there's also times I've wanted a way to manipulate what * would
> normally do. In particular, *_except_for(field_list), and *_replace(
> regexp_replace to run on each field name). If those existed (and maybe a
> way to combine them), it wouldn't be terribly hard for you do handle
> your sled query with something like:
>
> SELECT s.*, l.*( s/.*/left_%/ ), r.*( s/.*/right_& )
>   FROM sled s JOIN runner l ON ... JOIN runner r ON ...

It certainly look nasty.

But in the long run I strongly believe in peoples ability to "settle for
conventions", and I think I could find my ways with that construct, if
only it was possible. Not that I'd prefere it to the explicit aliasing
for aliased table coluns, syntactically inside column alias list. My
personal point of view is that:
1. "a star" in select is not so harmfull, since backend gives out the
names along with the data; and you cen see them in psql output and
retrieve them from client library (libpq) thus adopting for any order "a
star" happen to create.
2. in all other cases (from which I know: table aliases and inserts),
the backend does not interfere only when your error in arrangeing the
list results in a data type missmatch. this is wrong.

But anyway, thenx for pointing me to column aliasing, which I didn't
know before.

-R


В списке pgsql-general по дате отправления:

Предыдущее
От: Marc Mamin
Дата:
Сообщение: Re: Duplicate rows during pg_dump
Следующее
От: Gavin Flower
Дата:
Сообщение: Re: Recursive Arrays 101