Warn users that "tsvector" is not implemented in the page "Porting from PostgreSQL"

[superboum]

Re: Porting from PostgreSQL

Issue Description

tsvector type is not supported by cockroach

ProgrammingError: syntax error at or near "tsvector"
2018-02-11 16:22:05,307 - twisted - 131 - ERROR - - DETAIL:  source SQL:
2018-02-11 16:22:05,308 - twisted - 131 - ERROR - - CREATE TABLE IF NOT EXISTS event_search ( event_id TEXT, room_id TEXT, sender TEXT, key TEXT, vector tsvector )
2018-02-11 16:22:05,308 - twisted - 131 - ERROR - -                                                                                                      ^
2018-02-11 16:22:05,308 - twisted - 131 - ERROR - - HINT:  try \h CREATE TABLE

tsvector on postgre documentation

The tsvector type represents a document in a form suited for text search

Suggested Resolution

Might be a good idea to document it here ?

[jseldess]

Thanks for reporting this, @superboum.

@awoods187, @knz, this seems to be a case of a data type that isn't in the sql standard and so isn't represented on our Detailed SQL Support page or Postgres' corresponding page? How do we capture this type of discrepancy with what looks like a postgres-specific type?

[knz]

It's not just a pg-specific type, it's the tip of the iceberg that is postgres' support for full-text search. Just a line saying "this type is not supported" does not IMHO sufficiently acknowledge the breadth of what the user is asking for.

[jseldess]

@superboum, we have a broader tracking issue for full-text search, if you want to follow or comment on it: cockroachdb/cockroach#7821.

@knz, I understand your point that saying "this type isn't supported" isn't sufficient. What would you suggest we do in the short-term in the docs? I just noticed that on https://www.cockroachlabs.com/docs/dev/sql-feature-support.html, we mark "full-text indexes" as unsupported.

[jseldess]

@knz, ping on my last comment.

[knz]

Sorry I haven't answered to this earlier.

In an ideal world we we can do infinite work in zero time, we'd learn about all the features in pg that are inter-related to support full-text search.

Then we'd make a table of all these related features under a section header "Support for PostgreSQL features related to full text search". Then for each row in this table we'd say whether it's supported in CockroachDB and/or whether there is a related feature available.

This general idea is equally applicable to other things in PostgreSQL that have a simple name but technically are supported by a diversity of seemingly-unrelated features. For example, "JSON Support" requires both a JSON data type, inverted indexes and a series of built-in functions. Without inverted indexes, users would likely not consider that JSON support was complete. Interestingly, I personally think our JSON support is not complete because we are missing a couple built-in functions.

I am not saying we should spend that time now, but in general for the future I would recommend that any doc project for a high-level feature combines with some preliminary research in the pg docs to find the various things that are connected together, and report on that in our compatibility page.

[jseldess]

Thanks, @knz. For now, let's rely on the high-level feature being called out in our sql support matrix. Your guidance is great for these cases going forward.