Tom Lane wrote: > Gregory Stark <[EMAIL PROTECTED]> 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
Yes, that is what I was suggesting because as I mentioned TEXT already functions fine as tsquery. > 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. Because of the special behavior of & and |, I assume tsquery and tsvector cannot be the same data type. > 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. Yes, this is a good analogy. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
