[HACKERS] Rethinking ts_debug() output

2007-10-21 Thread Tom Lane
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

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [HACKERS] Rethinking ts_debug() output

2007-10-21 Thread Pavel Stehule
2007/10/22, Tom Lane [EMAIL PROTECTED]:
 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


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster