On 7/31/17, Jeffrey Mattox wrote:
> Is there any way to predict what error a (buggy) legacy app will receive, or
> is that dependent on the wrapper?
Dependent on the wrapper, unfortunately.
D. Richard Hipp
Is there any way to predict what error a (buggy) legacy app will receive, or is
that dependent on the wrapper?
sqlite-users mailing list
On 7/31/17, Bob Friesenhahn wrote:
> For our own applications we are often doing a wildcard select and
> using a feature of Python APSW to learn the available column names so
> we know the columns which were available.
That should continue to operate as before
On Mon, 31 Jul 2017, Peter Da Silva wrote:
Any application that depends on column names should be using “AS”
anyway, might as well break them sooner.
Any unintended change in behavior should be considered to be a bug.
There are a great many existing queries which do not use AS statements
On 7/31/17, jose isaias cabrera wrote:
> Funny. :-) (the sneezing lately...)
> I say, let's add the change to 3.20.0.
The patch is on the 3.20.0 branch. We are testing the 4th release
Thanks for the feedback.
D. Richard Hipp
Funny. :-) (the sneezing lately...)
I say, let's add the change to 3.20.0.
From: Peter Da Silva
Sent: Monday, July 31, 2017 11:58 AM
To: SQLite mailing list
Subject: Re: [sqlite] Poll: Include the recent sqlite3_column_name() fix in
the upcoming 3.20.0 release
Richard Hipp wrote:
> Cons: (5) The change might cause breakage for legacy applications that
> depend on the older (arguably buggy) behavior. (6) This seems like a
> big change to receive so little beta exposure prior to the official
I doubt that there are many applications that both
Merge it now.
As stated in documentation: "The SQLite documentation clearly states that,
if there is no AS clause, the names of output columns are indeterminate,
arbitrary, and subject to change." It would be my hope that legacy
applications exploiting the returned column name given said
Any application that depends on column names should be using “AS” anyway, might
as well break them sooner.
Disclaimer: I’m probably guilty of depending on column names without “AS”,
which explains why I’ve been sneezing so much lately.
On 7/31/17, 10:21 AM, "sqlite-users on behalf of Richard
On 31 Jul 2017, at 17:21, Richard Hipp wrote:
> Ticket https://sqlite.org/src/info/de3403bf5ae5f72ed describes a
> problem with column naming, and a proposed solution. Today's
> question: Should the proposed solution be merged into the 3.20.0
Robert M. Münch, CEO
IMHO the inconsistency is a bug of sorts and so would “vote” for a merge now.
In a sense applications that risk breaking are due to hacking around what is
documented. And if the change is going to happen it might as well be now along
with the major versions change.
Ticket https://sqlite.org/src/info/de3403bf5ae5f72ed describes a
problem with column naming, and a proposed solution. Today's
question: Should the proposed solution be merged into the 3.20.0
Pros: (1) The change makes column names more consistent. (2) The
change fixes some breakage
Mail list logo