Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SQLite should have (Rust-style) editions

mort.coffee

Post reply on HN
Print view View original

181–186 of 186 posts

Re: SQLite should have (Rust-style) editions

#181

Post by bambax »

imtringued wrote: post #141
bambax wrote: post #95

> I don't think I need to explain why it's a bad idea for a database to be so careless about data validation. Well, loose typing can be extremely useful, and having a type of "ANY" would not replace it. I have built recently an accounting reconciliation system to find discrepancies in data coming from a large variety of sources: some from proper database engines (MySQL MariaDB), but most from proprietary systems that…

You're using CSV, what did you expect? CSV was never meant for data exchange between two systems that do not know of each other's existence. Basically every CSV file is its own dialect.

I am not "using" CSV, I am forced to use it.

Re: SQLite should have (Rust-style) editions

#182

Post by bambax »

mickeyp wrote: post #105
bambax wrote: post #95

> I don't think I need to explain why it's a bad idea for a database to be so careless about data validation. Well, loose typing can be extremely useful, and having a type of "ANY" would not replace it. I have built recently an accounting reconciliation system to find discrepancies in data coming from a large variety of sources: some from proper database engines (MySQL MariaDB), but most from proprietary systems that…

Your... solution to bad ETL data is to go "let's keep it this way"? You can already "store whatever you want" in a serious database that respects types by default. It's called a blob or if you must, a text/varchar.

Yes! keeping it that way helps with traceability. The point is not to fix the data, it is to understand where corruption happens.

Re: SQLite should have (Rust-style) editions

#183

Post by Rygian »

ncruces wrote: post #180
Rygian wrote: post #176

Earlier quoted context omitted.

Not the author of the article, but I think you are overthinking the issue. New database ⇒ use the proposed new magic PRAGMA, start with sane defaults. Existing database ⇒ don't touch anything, keep legacy "suboptimal" defaults.

The forum post I linked to has a 3 line example: CREATE TABLE t1(a DATE, b JSON); PRAGMA strict=ON; INSERT INTO t1 VALUES(a,b) VALUES(?1,?2); You (or the author) can replace the non-existent `PRAGMA strict` with whatever editions thingy you're proposing. Just, you know, explain what should happens when you do this, because the creator of SQLite doesn't know . When doing so consider the file format, how schema is stor…

I would go with something like "Syntax error: pragma strict must appear before any table creation. " and consider that db file unusable.

Re: SQLite should have (Rust-style) editions

#184

Post by lelanthran »

bashauma wrote: post #178
lelanthran wrote: post #148

Earlier quoted context omitted.

> Now we need this for C/C++, which have much legacy stuff which ought to go away for new code. In C++, certainly. In C, though, what do you not do in C23 that you was doing in C99?

IIRC gets() ?

I don't think that counts - fgets (the safer replacement) was already in C89.

"Modern C" by 1999 already included "Don't use gets()"

Re: SQLite should have (Rust-style) editions

#186

Post by Animats »

lelanthran wrote: post #184
bashauma wrote: post #178

Earlier quoted context omitted.

IIRC gets() ?

I don't think that counts - fgets (the safer replacement) was already in C89. "Modern C" by 1999 already included "Don't use gets()"

The key concept of an "edition" is that you can deprecate stuff. "gets()" should have been pulled from the standard library around 1990 or so, along with "strcat" and its frenemies.
Post reply on HN