Re: [sqlite] feature request - field exclusion list in select list

This is altogether bad practice. You should always define what fields you want. Using Select * is just asking for trouble. To limit the number of fields that are accessible to a process/user/program, you should use a view. With a view you can of course then use Select * but that's not the point.

Re: [sqlite] feature request - field exclusion list in select list

Stephan Wehner wrote: > On Sun, Sep 27, 2009 at 5:19 PM, Darren Duncan > wrote: > >> Following my previous message to the sqlite-users list, I've done a bit more >> research and decided to escalate my reply to a formal feature request. >> >> I was initially going to

Re: [sqlite] feature request - field exclusion list in select list

On 28 Sep 2009, at 5:51am, Darren Duncan wrote: > Robustness comes in several ways. One is that with less code mass > their tends > to be fewer places to have bugs, all other things equal; when you make > developers write more, they are more likely to make mistakes. > Another piece of >

Re: [sqlite] feature request - field exclusion list in select list

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Darren Duncan wrote: > The main rationale for the feature I mention is code brevity, For more context, what language are you writing your code in and how do you get the contents of each column. Using the C api there are 3 ways: 1 - Explicit:

Re: [sqlite] feature request - field exclusion list in select list

On Sun, Sep 27, 2009 at 5:19 PM, Darren Duncan wrote: > Following my previous message to the sqlite-users list, I've done a bit more > research and decided to escalate my reply to a formal feature request. > > I was initially going to file a ticket, but it seems that

Re: [sqlite] feature request - field exclusion list in select list

Roger Binns wrote: >> intended for >> use in situations where users do want most of the fields from a source but >> don't >> want a few. > > What is the harm in the extra fields being returned? Sure they take up a > few bytes more space but that isn't a big deal. In tables where there may >

Re: [sqlite] feature request - field exclusion list in select list

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Darren Duncan wrote: > I was initially going to file a ticket, but it seems that non-registered > SQLite > developers can't do that anymore, and we're supposed to do it on sqlite-users > where a non-registered developer would then distill list

Re: [sqlite] feature request - field exclusion list in select list

Jean-Christophe Deschamps wrote: > Darren, > > At 02:19 28/09/2009, you wrote: > ´¯¯¯ >> So my proposed "" is identical to the old "> sublist>", and my addition is the optional EXCEPT plus list of not >> derived columns. >> >> Note that I'm not stuck on the keyword EXCEPT, but it should be a

Re: [sqlite] feature request - field exclusion list in select list

Oops, let me try again! >SELECT ALLBUT foo FROM t ... Typing error! Should be SELECT * ALLBUT foo FROM t ... Could be as well SELECT * BUTNOT foo, bar FROM t ... The risk seems much higher with words like SAFE or WITHOUT, which perhaps have greater probability of being used in some

Re: [sqlite] feature request - field exclusion list in select list

Darren, At 02:19 28/09/2009, you wrote: ´¯¯¯ >So my proposed "" is identical to the old "sublist>", and my addition is the optional EXCEPT plus list of not >derived columns. > >Note that I'm not stuck on the keyword EXCEPT, but it should be a word >that >reads similarly. `--- I would love to

[sqlite] feature request - field exclusion list in select list

Following my previous message to the sqlite-users list, I've done a bit more research and decided to escalate my reply to a formal feature request. I was initially going to file a ticket, but it seems that non-registered SQLite developers can't do that anymore, and we're supposed to do it on