Igor/Cezary, It is remarkable how 'struct Parse' already contains the constraint name as Cezary pointed out. -> Token constraintName;/* Name of the constraint currently being parsed */ But is not included in the 'struct FKey' linked list node that is reeled in to produce columns in the PRAGMA report. For the official release, presumably, test cases would have to be added in addition to simply hooking it up as suggested.
In the meantime, parsing wouldn't be difficult even with primitive built-in SQL string functions. Consider how the constraint name must occur within the comma delimited part of the well formed CREATE TABLE statement. When obtained from sqlite_master, the statement is guaranteed to be well formed. Simply examine each comma delimited candidate part. If present, the first word between keyword CONSTRAINT and keyword REFERENCES is the constraint name. Peter On Sun, Dec 10, 2017 at 7:29 PM, Igor Korot <ikoro...@gmail.com> wrote: > Hi, > > On Sun, Dec 10, 2017 at 8:30 PM, Cezary H. Noweta <c...@poczta.onet.pl> > wrote: > > Hello, > > > > On 2017-12-11 01:04, Igor Korot wrote: > > > >> On Sun, Dec 10, 2017 at 5:01 PM, Cezary H. Noweta <c...@poczta.onet.pl> > >> wrote: > > > > > >>> On 2017-12-10 07:21, Igor Korot wrote: > > > > > >>>> The CREATE TABLE statement supports the following syntax: > >>>> > >>>> CREATE TABLE( <column_name_list>, CONSTRAINT <fk_name> FOREIGN > >>>> KEY(<fk_field>) REFERENCES <ref_table>(ref_column_list>); > > > > > >>>> [...] If not - does this mean that the only way to get the name is to > >>>> parse the > >>>> sql > >>>> from sqlite_master? Or there is a better way? > > > > > >>> The answer is ``not''. Constraint names are ignored and disappearing > >>> without > >>> a trace except for ``CHECK'' constraint (the name is used to build an > >>> error > >>> message). Unparsed ``sql'' column of ``sqlite_master'' is the sole > place > >>> which contains an indirect info about ``FOREIGN KEY'' constraint's > name. > > > > > >> Thank you for confirming. > > > > You are welcome. BTW, SQLite parses SQL every time it creates a table > > (by a SQL command or after an opening of BTree file) -- I believe there > > is no better way. You do not need to parse SQL on your own (it is hard, > > if not impossible, to establish a link between a name and a particular > > constraint). All you need is to append ``char *'' field to ``struct > > FKey'' and to inject a function ``build.c:sqlite3CreateForeignKey()'': > > ``pParse->constraintName'' will contain the constraint's name (note > > that the name is not dequoted -- you will have to dequote it; look at > > ``build.c:sqlite3AddCheckConstraint()'' to know how assigning of a > > constraint's name is done). This will allow you to build your own map of > > ``FOREIGN KEY'' names. For example, if you want to expand ``PRAGMA > > foreign_key_list'', go to ``pragma.c:sqlite3Pragma():case > > PragTyp_FOREIGN_KEY_LIST:'' and append new FKey's field. > > Thank you, but I need to keep the official SQLite code. > > > > > > > > -- best regards > > > > Cezary H. Noweta > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
