Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Tom Lane" <[EMAIL PROTECTED]> writes:
>>> True. I'll bet you don't like ts_stat() either.
>> It seems the right way interface here wouldn't be too different from what's
>> there. ...
> I'm not sure that's so muc
BTW, I noticed while poking at this that the 2-arg form of ts_rewrite()
is labeled proretset = true in pg_proc.h. This must be a typo, since
a moment's glance at the code shows it cannot return a set. Good thing
we didn't ship beta2 yet ...
regards, tom lane
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> True. I'll bet you don't like ts_stat() either.
> It seems the right way interface here wouldn't be too different from what's
> there. All we need is a SRF which takes a single tsvector and returns the set
> of
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> The two-argument form may not be actively broken but it sounds not very
>> integrated. Passing a string which is then planned as an SQL query is not
>> very
>> SQL-ish.
>
> True. I'll bet you don't like ts_stat
Gregory Stark <[EMAIL PROTECTED]> writes:
> The two-argument form may not be actively broken but it sounds not very
> integrated. Passing a string which is then planned as an SQL query is not very
> SQL-ish.
True. I'll bet you don't like ts_stat() either.
regards, tom lan
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Since we're already committed to an initdb for beta2, it's not quite too
> late to reconsider the API here. My feeling at the moment is that we
> should just drop the aggregate form of ts_rewrite; it does nothing you
> can't do better with the two-argument
