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

From: Rafal Pietrak <rafal(at)ztk-rp(dot)eu>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Dane Foster <studdugie(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: partial JOIN (was: ID column naming convention)
Date: 2015-10-26 07:54:52
Message-ID: 562DDC4C.8000909@ztk-rp.eu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Gavin Flower 2015-10-26 08:08:34 Re: Recursive Arrays 101
Previous Message Marc Mamin 2015-10-26 07:49:49 Re: Duplicate rows during pg_dump