Gregory Stark <stark@enterprisedb.com> writes:
> How would that happen if there wasn't a tsquery type?
I don't think Bruce is suggesting that the search operand can really
be plain text (or if he is, he's nuts). The question here is whether
there's really a need for a distinction between tsvector and tsquery
datatypes; could we have tsvector serve both purposes instead?
I can see that there are differences: tsquery can tell the difference
between "x AND y" and "x OR y", whereas tsvector just knows "x, y".
A superset datatype that can do both is certainly possible, but whether
it's practical, or would be easier to use than the current design,
I dunno.
Perhaps a suitable analogy is regexp pattern matching. Traditionally
regexps are conceived of as strings, but if they'd originated in more
strongly typed languages than they did, they'd certainly be thought
of as a distinct data type. Had we implemented ~ as taking a right
operand of type 'regexp', we could win on a number of levels: entry-time
syntax checking for regexps, and a precompiled internal representation,
for instance. For regexps it seems clear to me that the target text
string and the pattern really are different datatypes, and fuzzing that
distinction is not an improvement.
regards, tom lane
