On 9 Jul 2017, at 3:50am, petern wrote:
> This is what SQLite 3.19.3 VALUES clause presently does independently of
> shell.c. My question would be, is this feature going to produce stable
> column names going forward caveat the strange behavior of double quotes.
On Sat, Jul 8, 2017 at 8:50 PM, petern wrote:
> The bug here is how the VALUES logic can't have it both ways. If double
> quotes are invalid for column value literals they should be rejected or at
> least ignored. They should not suddenly be injected into the column
On Saturday, 8 July, 2017 19:02, Simon Slavin wrote:
> On 9 Jul 2017, at 1:44am, Keith Medcalf wrote:
> > I can't visualize what you mean. Something like:
> > create view constants (col1, col2) as values (1,1), (1,2);
>
> > seems the most
A lot of replies. To be clear, this is not a quirk of the shell and I'm
not just monkeying around looking for haphazard guesses about why I'm
"trying to change the SQL standard". The following query sent through
sqlite3_exec() produces the following output:
SELECT max([],[:1]) FROM (VALUES
On 9 Jul 2017, at 1:44am, Keith Medcalf wrote:
> I can't visualize what you mean. Something like:
>
> create view constants (col1, col2) as values (1,1), (1,2);
>
> seems the most straightforward to me, and allows you to assign column names
> to the data.
But that’s
> >> If you want columns to have names, create a TABLE or VIEW,
> >> and specify what those names should be using "AS".
> > You would define the column names in the definition of the table or the
> > view. There would not be any AS clauses (they will not work).
> Sorry, I meant that the "AS"
On 9 Jul 2017, at 1:24am, Keith Medcalf wrote:
>> If you want columns to have names, create a TABLE or VIEW,
>> and specify what those names should be using "AS".
>
> You would define the column names in the definition of the table or the view.
> There would not be any
> If you want columns to have names, create a TABLE or VIEW,
> and specify what those names should be using "AS".
You would define the column names in the definition of the table or the view.
There would not be any AS clauses (they will not work).
Thanks Ryan.
Thank you very much for the detailed analysis on how the column names are
arrived at.
Presumably the column names "",":1",":2",... will be stable in future. I
use them frequently in the following pattern.
SELECT custom_aggregate("",":1") FROM (VALUES (1,2),(3,4));
Or, with
On 9 Jul 2017, at 12:53am, petern wrote:
> Is there some sort of easter egg there? Is there a way for VALUE to take
> the first row exclusively as column names? Perhaps there is a trick with
> other special characters?
The thing you’re doing does not have
I was hoping someone could shed light on what is actually going on in the
VALUE clause.
Is there some sort of easter egg there? Is there a way for VALUE to take
the first row exclusively as column names? Perhaps there is a trick with
other special characters?
Trying the obvious only produces
On 2017/07/08 9:36 PM, petern wrote:
Why does the choice of data value quotation mark influence the output
column name of the inline VALUES clause? [This quirk was the origin of a
recent bug in a current project.]
As to the "Why" question: It is because Double-Quotes denote
Identifiers, not
On 7/8/17, Roberto C. wrote:
>
> while trying to install and sqlite package for R statistical language
> (Rsqlite) I came across I bug: i could not compile the package with the
> intel compiler ICC / ICPC. You can find the whole discussion (and the
> solution) here -
On 8 Jul 2017, at 8:36pm, petern wrote:
> Why does the choice of data value quotation mark influence the output
> column name of the inline VALUES clause?
I admire your set of examples, which show the behaviour well.
Column names in SQLite are not dependable
Why does the choice of data value quotation mark influence the output
column name of the inline VALUES clause? [This quirk was the origin of a
recent bug in a current project.]
sqlite> .version
SQLite 3.19.3 2017-06-08 14:26:16
0ee482a1e0eae22e08edc8978c9733a96603d4509645f348ebf55b579e89636b
On 7/8/17, Roberto C. wrote:
>
> The undefined symbol, __builtin_mul_overflow, is a GCC primitive. SQLite
> has the option to call it directly. It's supposed to disable itself through
> a some pre-processor checks if it's not supported by the current compiler,
> but I believe
Hi,
while trying to install and sqlite package for R statistical language
(Rsqlite) I came across I bug: i could not compile the package with the
intel compiler ICC / ICPC. You can find the whole discussion (and the
solution) here - https://github.com/rstats-db/RSQLite/issues/223
However, the
17 matches
Mail list logo