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 much cleaner than
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 words from
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 form,
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 lane
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() either.
It
