| From: | Darren Duncan <darren(at)darrenduncan(dot)net> |
|---|---|
| To: | Mark Mielke <mark(at)mark(dot)mielke(dot)cc> |
| Cc: | Eric Ridge <eebbrr(at)gmail(dot)com>, David Wilson <david(dot)t(dot)wilson(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com> |
| Subject: | Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."? |
| Date: | 2011-10-31 00:25:42 |
| Message-ID: | 4EADEB06.8080307@darrenduncan.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Mark Mielke wrote:
> On 10/30/2011 03:50 PM, Eric Ridge wrote:
>> Changes of omission can break your code just as easily.
>
> I think I wasn't as clear as I intended. In many ways, I think use of
> "*" in the first place is wrong for code (despite that I do it as well).
> Therefore, "* EXCLUDING (...)" would also be wrong. It comes to "does
> the code know what it wants?"
<snip>
>
> "select *" is not deterministic from a programming perspective.
I understand what you're saying. However, we're stuck with * because it is in
the standard and is widely used, and if we have * anyway, then the exclusion
proposal is just an enhancement to that. So there is no reason to reject the
complementary columns feature because of the problems with "select *"; you might
as well argue to get rid of "select *". -- Darren Duncan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-10-31 00:56:53 | Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."? |
| Previous Message | Christopher Browne | 2011-10-31 00:16:47 | Re: Thoughts on "SELECT * EXCLUDING (...) FROM ..."? |