Re: [sqlite] Poll: Include the recent sqlite3_column_name() fix in the upcoming 3.20.0 release?

2017-07-31 Thread Richard Hipp
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 d...@sqlite.org ___

Re: [sqlite] Poll: Include the recent sqlite3_column_name() fix in the upcoming 3.20.0 release?

2017-07-31 Thread Jeffrey Mattox
Is there any way to predict what error a (buggy) legacy app will receive, or is that dependent on the wrapper? Jeff ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org

Re: [sqlite] Poll: Include the recent sqlite3_column_name() fix in the upcoming 3.20.0 release?

2017-07-31 Thread Richard Hipp
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

Re: [sqlite] Poll: Include the recent sqlite3_column_name() fix in the upcoming 3.20.0 release?

2017-07-31 Thread Bob Friesenhahn
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

Re: [sqlite] Poll: Include the recent sqlite3_column_name() fix in the upcoming 3.20.0 release?

2017-07-31 Thread Richard Hipp
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 candidate now. Thanks for the feedback. -- D. Richard Hipp d...@sqlite.org

Re: [sqlite] Poll: Include the recent sqlite3_column_name() fix in the upcoming 3.20.0 release?

2017-07-31 Thread jose isaias cabrera
Funny. :-) (the sneezing lately...) I say, let's add the change to 3.20.0. -Original Message- 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

Re: [sqlite] Poll: Include the recent sqlite3_column_name() fix in the upcoming 3.20.0 release?

2017-07-31 Thread Clemens Ladisch
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 > release. I doubt that there are many applications that both

Re: [sqlite] Poll: Include the recent sqlite3_column_name() fix in the upcoming 3.20.0 release?

2017-07-31 Thread Don V Nielsen
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

Re: [sqlite] Poll: Include the recent sqlite3_column_name() fix in the upcoming 3.20.0 release?

2017-07-31 Thread Peter Da Silva
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

Re: [sqlite] Poll: Include the recent sqlite3_column_name() fix in the upcoming 3.20.0 release?

2017-07-31 Thread Robert M. Münch
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 > release? +1 yes -- Robert M. Münch, CEO M: +41

Re: [sqlite] Poll: Include the recent sqlite3_column_name() fix in the upcoming 3.20.0 release?

2017-07-31 Thread Neville Dastur
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. -- L:

[sqlite] Poll: Include the recent sqlite3_column_name() fix in the upcoming 3.20.0 release?

2017-07-31 Thread Richard Hipp
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 release? Pros: (1) The change makes column names more consistent. (2) The change fixes some breakage