> 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 (with
the DBMS) the build in necesary documentation selft conained inside on the
DB, that its helfull for all, (very)
> - which you don't have when they are treated like Meta-data.
> That said, only some DBs include comment in-schema specifiers, like
> Postgres and MySQL as Richard pointed out,
make this in master db can make obvously incompatible and can made grow the
size depends of the comment size and amount of the tables and columns..
but, taking in considerations that today nobody of us take care about that
(machines are so powerfully right?).... so makin a extra schema its enought
> Your request has been noted, Thank you for the suggestion.
many thanks! really appreciated!
this request was made prevously by another person, see archives.. many many
also was widelly requested in internet network by many years, but due the
very complicated behavior of the request / bugtraking system for sqlite..
no much was received here
> in MSSQL you have to add a comment by a whole other mechanism.
??? in my job we have complete SQL SERVER 2014 SP1 and performance need a
complete dell r600 and usage of the compelte 1T of RAM need extra
licences.. and more extra and extra "integrations" and then u mention that:
> Easy sailor... There is no need for you use that specific "stupid guindows
> tool", it's simply that the tool had solved the comment problem by parsing
> the schema, and you could do something like it.
we use (again) MS-like soft due "recomended", these king of
"recomendations" was the reason of the problem.. we have to paid, mid-usage
of a software we cannot migrate easy now! and we cannot use "complete"
today without a "grow-deep" dependence of the MS ...
sqlite-users mailing list
[hidden email] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> 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 255 chars and if any other non valid were found,
ignore it! like tabs, newlines, etc.. truncate
> I’m utterly against anything that tries to read C-style comments.
> Comments are comments. Computers are meant to ignore them to the point
> that they don’t even know they exist.
> On the other hand, if we establish a standard for storing comments in
> database tables — which would require a consistent table name, column
> names, and values — it might take too much extra time to show those
> comments as an extra column in the response to PRAGMA tale_info() and
> similar PRAGMAs. But I think it’s overkill. Anyone who would want that
> would know how to retrieve the information.
and if db's configure it to by default do not show this "extra" information?