On Sun, Oct 30, 2011 at 1:10 AM, Darren Duncan <darren@darrenduncan.net> wrote:
> The SQL level is exactly the correct and proper place to do this.
>
> Its all about mathematical parity. That is the primary reason to do it.
>
> - "SELECT *" gives you a whole set.
> - "SELECT foo, bar" gives you a subset of that.
> - "SELECT ALL BUT foo, bar" gives you the complementary subset.
That's not actually entirely true given the usual SQL (and
mathematical) meaning of "set". This feature relates to the set of
attributes returned regarding elements of the returned set, not the
set itself- the actual returned set is identical regardless of the
column-specifier formulation. Claiming this as an SQL mathematical
purity issue is a bit disingenuous, as SQL set manipulation takes
place at the member level rather than the attribute level- SQL is
otherwise quite explicit about requiring explicit listings of the
attributes that the client is interested in regarding a returned set
of member rows.
>
> Arguing against this is like arguing against a subtraction operator, because
> we can emulate using addition plus negation, or saying subtraction should
> just be a special filter in a client app.
That would be true if this was an argument against "WHERE" or
"EXCEPT". Column specification and row specification are very
different and cannot be conflated.
That's not to say this proposal is without merit, merely that your
arguments for it are poorly founded and not particularly relevant.
--
- David T. Wilson
david.t.wilson@gmail.com