Re: gsoc, oprrest function for text search take 2 - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: gsoc, oprrest function for text search take 2
Date
Msg-id 48B5065D.6050702@enterprisedb.com
Whole thread Raw
In response to Re: gsoc, oprrest function for text search take 2  (Jan Urbański <j.urbanski@students.mimuw.edu.pl>)
List pgsql-hackers
Jan Urbański wrote:
> Tom Lane wrote:
>> Jan Urbański <j.urbanski@students.mimuw.edu.pl> 
>> writes:
>>> Simon Riggs wrote:
>>>> put it in a file called selfuncs_ts.c so it is similar to the existing
>>>> filename?
>>
>>> I followed the pattern of ts_parse.c, ts_utils.c and so on.
>>> Also, I see geo_selfuncs.c. No big deal, though, I can move it.
>>
>> Given the precedent of geo_selfuncs.c, I think you were right the
>> first time.  A more interesting question is whether it should just
>> get folded into selfuncs.c ...
> 
> selfuncs.c is a 5.8k lines beast, I felt a bit intimidated when first 
> opened it. The code in ts_selfuncs.c relies strongly on what the code in 
> ts_typanalyze.c does and that was another reason for putting in in its 
> own file next to ts_typanalyze.c. I don't really care to be honest, 
> might as well stick it into selfuncs.c.

I would leave the code in ts_selfuncs.c like you did. The stuff in 
selfuncs.c is pretty generic, not related to any specific data type. 
With the exception of the regex and LIKE selectivity functions, but 
those should rather be moved to a separate file, say pattern_selfuncs.c. 
There's also plenty of datatype-specific code in convert_to_scalar() and 
its subroutines, but even the comment there says that it's a hack.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Jan Urbański
Date:
Subject: Re: gsoc, oprrest function for text search take 2
Next
From: Grant Finnemore
Date:
Subject: Re: Proposal to sync SET ROLE and pg_stat_activity