Re: Rethinking ts_debug() output - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Rethinking ts_debug() output
Date
Msg-id 162867790710212208u612fb64bgee089204fd4f13ef@mail.gmail.com
Whole thread Raw
In response to Rethinking ts_debug() output  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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
>


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Ready for beta2?
Next
From: "Pavel Stehule"
Date:
Subject: Re: Ready for beta2?