Re: partial JOIN (was: ID column naming convention) - Mailing list pgsql-general

From Rafal Pietrak
Subject Re: partial JOIN (was: ID column naming convention)
Date
Msg-id 562DDC4C.8000909@ztk-rp.eu
Whole thread Raw
In response to Re: partial JOIN (was: ID column naming convention)  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List 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 by date:

Previous
From: Marc Mamin
Date:
Subject: Re: Duplicate rows during pg_dump
Next
From: Gavin Flower
Date:
Subject: Re: Recursive Arrays 101