Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On Thu, Jun 8, 2017 at 12:15 PM, Jens Alfke wrote: > SQLite is primarily an _embedded_ database library. In that use case, > comments on the schema properly belong in the program that creates the > database, next to the sqlite3_exec("CREATE TABLE…”) calls. > > I realize that

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

SQLite is primarily an _embedded_ database library. In that use case, comments on the schema properly belong in the program that creates the database, next to the sqlite3_exec("CREATE TABLE…”) calls. I realize that when SQLite is being used as a command-line DBM tool, having comments in the

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

"CREATE TABLE meta_comments" Simon, isn't your approach the most logical solution rather than incorporating a comment column into the master? Once incorporated, wouldn't you be opening yourself up to a litany of "Not the way we work", "We need feature x to be useful", "What if we want a null

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

2017-06-07 13:57 GMT-04:00 Simon Slavin : > The work of parsing comments in the CREATE TABLE command ? I don’t think > anyone else thinks this is worth working on. Discussion in this list has > come up with many reasons why it’s a poor way to store comments, including >

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

ipost github as example.. there a sourceforge git capabilities over large years.. also You can't be 100% certain that Ricahd resources is going to be online tomorrow.. sf.net, github, gitlab and googlecode are still only voer many years... and all of them works with openid... for Stephen

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 6 Jun 2017, at 2:17pm, PICCORO McKAY Lenz wrote: > how its the status of this work? The work of parsing comments in the CREATE TABLE command ? I don’t think anyone else thinks this is worth working on. Discussion in this list has come up with many reasons why

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On Jun 7, 2017, at 10:37 AM, Stephen Chrzanowski wrote: > > You can't be 100% certain that GitHub is going to > be online tomorrow As well, we have plenty of history showing that we can’t trust the long-term availability or trustworthiness of third party hosting services.

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Why should Richard and other devs rely on something other than their own work and source control? You can't be 100% certain that GitHub is going to be online tomorrow, which means that a scramble to push code to another site is going to happen. You can't be certain that whatever comes after

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

They're using Fossil as the repository. You'll want to confirm the steps required, but the main access point is as follow (I believe): https://www.sqlite.org/src/login The main concern is that the functionality that you seek might not scale to the broader user base. You can always extend it

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

hello brian, what standars? reading deeply the sqlite site i not see the @issue buton@ only see that all contact way must be in the mail list... its a 21 century and ID urls its the standar way of integration... Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com 2017-06-07 12:12

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Not exactly. You're free to extend it yourself and submit it for consideration though. I think that you'll just need to adopt the same standards as are in use within the usual enhancements channels. Regards. Brian P Curley On Wed, Jun 7, 2017 at 12:09 PM, PICCORO McKAY Lenz

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

2017-06-07 9:59 GMT-04:00 Richard Hipp : > I would suggest, then, that you grab a copy of the SQLite source code, > put it on github, and start your own fork. You can then add whatever > new SQL commands you want. > > At this point, your chances of getting us to do your work for

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 6/7/17, PICCORO McKAY Lenz wrote: > the github issue tracker are more easy to send.. register can made with any > openid service.. no a complicated email out/of/time system.. its the 21 > century men I would suggest, then, that you grab a copy of the SQLite source

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

the github issue tracker are more easy to send.. register can made with any openid service.. no a complicated email out/of/time system.. its the 21 century men Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com 2017-06-07 9:24 GMT-04:00 Stephen Chrzanowski : >

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

What other way would there be? Just anonymous "Fix it, add this, do it now!" kind of messages? If you don't register, then anyone can start spamming the hell outta the message board. On Wed, Jun 7, 2017 at 9:15 AM, PICCORO McKAY Lenz wrote: > the problem its that for

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

the problem its that for making some noise or request users must register, send email, waith response aproval.. too complicated processs.. that's the reason Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com 2017-06-07 2:16 GMT-04:00 Daniel Kamil Kozar : > Patches

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Patches are still welcome, I guess. I haven't seen anybody claiming that this would be done in any way. On 6 June 2017 at 15:17, PICCORO McKAY Lenz wrote: > how its the status of this work? > > a limited implementation will be good! > > Lenz McKAY Gerardo (PICCORO) >

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

how its the status of this work? a limited implementation will be good! Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com 2017-03-15 12:24 GMT-04:00 Simon Slavin : > > On 15 Mar 2017, at 4:09pm, Dominique Devienne wrote: > > > On Wed, Mar

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

2017-03-15 12:24 GMT-04:00 Simon Slavin : > Problem is, it requires parsing the CREATE command looking for comments in > a certain format. Notoriously difficult, considering that they can contain > CR, LF, tab, and unforeseen Unicode characters. > well limit the comment to

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

2017-03-15 11:49 GMT-04:00 R Smith : > Well, the advantage of having comments in DB tables (as some suggested) is > also that you have the entire SQL language functions available to > manipulate the comments that's one firts reason that rely on the second, comment can handle

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 15 Mar 2017, at 4:09pm, Dominique Devienne wrote: > On Wed, Mar 15, 2017 at 4:57 PM, R Smith wrote: > >> I wonder, sqlite Devs, if a pragma or other adaption (such as the current >> pragma table_info()) or such could produce the same exact data but

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On Wed, Mar 15, 2017 at 4:57 PM, R Smith wrote: > I wonder, sqlite Devs, if a pragma or other adaption (such as the current > pragma table_info()) or such could produce the same exact data but with an > added field called "Comment" that simply gives the parsed comment from >

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 2017/03/15 5:36 PM, Richard Hipp wrote: On 3/15/17, Bob Friesenhahn wrote: On Wed, 15 Mar 2017, R Smith wrote: CREATE TABLE "test" ( "ID" INTEGER /* Here we add column comments */, "Name" TEXT /* Note the comma is AFTER the comment */, "EMail" TEXT

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 2017/03/15 5:15 PM, PICCORO McKAY Lenz wrote: so manual comment using C-like cannot do that, if i have a large set of DB's with minimal of 20 tables, its widelly tedious manage comments in that way that some here sugest me.. and later joint the db files for work? Well, the advantage of

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 3/15/17, Bob Friesenhahn wrote: > On Wed, 15 Mar 2017, R Smith wrote: >> >> CREATE TABLE "test" ( >> "ID" INTEGER /* Here we add column comments */, >> "Name" TEXT /* Note the comma is AFTER the comment */, >> "EMail" TEXT COLLATE NOCASE /* Username (Unique

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On Wed, 15 Mar 2017, R Smith wrote: What we do (typically), since SQLite supports C-type comment blocks /* ... */, is to add comment lines to the schema and they are preserved correctly. For example: CREATE TABLE "test" ( "ID" INTEGER /* Here we add column comments */, "Name" TEXT /* Note

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

the idea its that many tools generated (due portability and compability) sql script with a optional keyword COMMENT on each column definition.. this its xxtremely usefull for selft container documentation for many console users and rapid development so manual comment using C-like cannot do that,

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 15 Mar 2017, at 2:45pm, Bart Smissaert wrote: > Maybe it is simpler (no parsing needed) to have an extra table with a > unique column holding tablename_fieldname > and a second column holding the comment for that field. It’s common to see a four column table, with

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Maybe it is simpler (no parsing needed) to have an extra table with a unique column holding tablename_fieldname and a second column holding the comment for that field. RBS On 15 Mar 2017 10:35, "R Smith" wrote: > > On 2017/03/14 2:54 PM, PICCORO McKAY Lenz wrote: > >> an

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 15 Mar 2017, at 2:30pm, PICCORO McKAY Lenz wrote: > so can introduce a feature that converts all parts that have COMMENT '(\*)' > to /* COMMENT */ and stored? in the master part of the Database? It is unlikely that this will happen in SQLite3. What Brian is telling

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

hey their'e WIDELY USED keyword and practice in all mayor DBMS so can introduce a feature that converts all parts that have COMMENT '(\*)' to /* COMMENT */ and stored? in the master part of the Database? and NOTED THAT no many users comes here due the complicated behavior of report an issue...

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 15 Mar 2017, at 1:27pm, Brian Curley wrote: > The sqlite_master table will always preserve any comments embedded between > the "CREATE" and ";" keywords for a given table definition. Is this not > sufficient? I always found that interesting. I would have thought that

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

The sqlite_master table will always preserve any comments embedded between the "CREATE" and ";" keywords for a given table definition. Is this not sufficient? You can parse the sql for a table's record to retrieve comments, in whichever format you're using. I know that SQLite supports both single

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Just add a 'comments' table. Seems a lot of extra work and 'extra tools' needed to read the comments, which could potentially be missed. Add a 'comments' table with a 'comment' field which you can even add dates, usernames, etc, to. Thanks, Chris On Wed, Mar 15, 2017 at 11:12 AM, Clemens

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

PICCORO McKAY Lenz wrote: > an important feature in a DB its the column field that gives to developers > metadata info INDEPENDENT of the tecnologies used, due by this way with a > simple text editor in generated script developer can read and use minimal > info for understanding structure ...

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

I usually add a table with comments to other tables and fields for this. That does the trick for me. Is there another way to do it? 2017-03-14 13:54 GMT+01:00 PICCORO McKAY Lenz : > an important feature in a DB its the column field that gives to developers > metadata info

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 2017/03/14 2:54 PM, PICCORO McKAY Lenz wrote: an important feature in a DB its the column field that gives to developers metadata info INDEPENDENT of the tecnologies used, due by this way with a simple text editor in generated script developer can read and use minimal info for understanding

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Can't you add it to the field name? For example for a field holding date of birth: DOB_INT or DOB_TXT. RBS On Tue, Mar 14, 2017 at 12:54 PM, PICCORO McKAY Lenz wrote: > an important feature in a DB its the column field that gives to developers > metadata info

[sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

an important feature in a DB its the column field that gives to developers metadata info INDEPENDENT of the tecnologies used, due by this way with a simple text editor in generated script developer can read and use minimal info for understanding structure ... its a minimal feature need in a