Обсуждение: Rethinking ts_debug() output
I hadn't realized till just now that ts_debug()'s output is not compatible with the way the function was defined in 8.2 contrib. But since apparently backwards-compatibility is not a controlling factor here, I have a couple suggestions: * It seems like a bad idea to merge the controlling-dictionary and resulting-lexemes values into a single text column. This may be readable enough, but it's pretty horrid if you want to do any postprocessing on the result. I suggest splitting this into a regdictionary column and a text[] column, both of which yield NULL for an unrecognized token. As far as I can see at the moment this will require two evaluations of the pg_ts_config_map sub-select, which is a tad annoying, but we shouldn't be foreclosing easy postprocessing of the result. * Personally I find the forced mixed-case names of the output columns to be pretty darn inconvenient when I want to do anything with the output. Since the previous incarnation of the function didn't use mixed-case names, it's obvious that there's no field experience suppporting this decision. May I suggest dropping the mixed-case names? It's not too late to reconsider this stuff before beta2 ... regards, tom lane
2007/10/22, Tom Lane <tgl@sss.pgh.pa.us>: > I hadn't realized till just now that ts_debug()'s output is not > compatible with the way the function was defined in 8.2 contrib. > But since apparently backwards-compatibility is not a controlling > factor here, I have a couple suggestions: > > * It seems like a bad idea to merge the controlling-dictionary and > resulting-lexemes values into a single text column. This may be > readable enough, but it's pretty horrid if you want to do any > postprocessing on the result. I suggest splitting this into a > regdictionary column and a text[] column, both of which yield NULL > for an unrecognized token. As far as I can see at the moment this > will require two evaluations of the pg_ts_config_map sub-select, > which is a tad annoying, but we shouldn't be foreclosing easy > postprocessing of the result. > + 1` > * Personally I find the forced mixed-case names of the output columns > to be pretty darn inconvenient when I want to do anything with the > output. Since the previous incarnation of the function didn't use > mixed-case names, it's obvious that there's no field experience > suppporting this decision. May I suggest dropping the mixed-case names? > > It's not too late to reconsider this stuff before beta2 ... > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate >