From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Rethinking ts_debug() output |
Date: | 2007-10-22 02:21:36 |
Message-ID: | 19632.1193019696@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-10-22 02:38:04 | Re: Ready for beta2? |
Previous Message | Joshua D. Drake | 2007-10-22 02:14:41 | Re: MVCC, undo log, and HOT |