| From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
|---|---|
| To: | Ken Tanzer <ken(dot)tanzer(at)gmail(dot)com> |
| Cc: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, PG-General Mailing List <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Two columns with same name in subselect--any way to SELECT without *? |
| Date: | 2018-01-07 07:33:56 |
| Message-ID: | CAKFQuwbNzT7LXttDUWxK3md_hdLTiuPpAmYyrJu36ZwsRaghqQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Saturday, January 6, 2018, Ken Tanzer <ken(dot)tanzer(at)gmail(dot)com> wrote:
>
> So having thought about this a little more, it seems like once you create
> a result set with identically-named columns, those columns are effectively
> crippled. In that they can be viewed (via SELECT *), but not referenced,
> used or acted upon in any way. Still just wanting to confirm this is/is
> not the case. Thanks!
>
I'm not really following the intent of the question but if your client API
allows for column references by position instead of name you can still
distinguish between them, too.
In subqueries or CREATE TABLE AS, no, the system, is going to force you to
differentiate them since all SQL references are by name.
David J.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | pinker | 2018-01-08 00:35:28 | Re: core system is getting unresponsive because over 300 cpu load |
| Previous Message | Ken Tanzer | 2018-01-07 07:01:41 | Re: Two columns with same name in subselect--any way to SELECT without *? |