On Sun, Apr 16, 2017 at 3:40 PM, Richard Hipp <[email protected]> wrote:
> On 4/16/17, Simon Slavin <[email protected]> wrote: > > > > On 16 Apr 2017, at 10:57pm, Timothy Stack <[email protected]> > > wrote: > > > >> UPDATE foo SET col0 = 'bar' WHERE hidden_field = 'baz' > >> > >> Having the real syntax, like the following, would be nice though: > >> > >> UPDATE foo('baz') SET col0 = 'bar' > > > > How would it know that 'baz' is a value for the column "hidden_field" > rather > > than some other column ? > > Table-valued functions are just virtual tables that allow parameters > to be used as constraints against the "hidden" columns of the virtual > table. The parameters match in order. The first parameter matches > against the first hidden column, and the second parameter matches > against the second hidden column, and so forth. > > That is, I'm guessing, what the OP means. > Yes, that is what I mean. Whether or not the suggest is a good idea is a different matter. I'm > skeptical. A function is typically not an l-value and is hence not > > typically something that can be modified. > Let's take the 'carray' extension[1] as an example. If I can read from an array in memory with the following statement: SELECT * FROM carray(0x7b3830, 10); Why shouldn't I be able to update that array using a similar syntax? tim [1] - https://sqlite.org/carray.html > > -- > D. Richard Hipp > [email protected] > _______________________________________________ > sqlite-users mailing list > [email protected] > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
