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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

jose isaias cabrera-3

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?

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 Hipp"
<[hidden email] on behalf of [hidden email]>
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?

    Pros:  (1)  The change makes column names more consistent.  (2) The
    change fixes some breakage caused by a query planner enhancement
    introduced in 3.19.0.  (3) The change makes column naming in SQLite
    work (more) like it does in PostgreSQL, MySQL, and SQLServer.  (4) The
    change will likely be in 3.21.0 even it it isn't in 3.20.0.  Better to
    go ahead and get over the pain of any breakage that results now,
    rather than putting it off until later.

    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.  (7) Making the merge will (or should) delay the release by a
    day or so.  The release was going to happen tomorrow (2017-08-01) but
    if we do the merge, I think the release should be postponed until
    2017-08-02 or 2017-08-03.

    Let me know your thoughts.   Replies to the mailing list are
    preferred, but private email directly to me is also accepted.
    --
    D. Richard Hipp
    [hidden email]
    _______________________________________________
    sqlite-users mailing list
    [hidden email]
    http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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
for each and every column returned.

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. If the column names are
sometimes not the same as the table definition then there will be
severe problems.

Bob
--
Bob Friesenhahn
[hidden email], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Richard Hipp-3
On 7/31/17, Bob Friesenhahn <[hidden email]> 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 with no changes.
Nevertheless, I encourage you to download a copy of the latest release
candidate and try it for yourself, to see if you have any problems.
--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Loading...