-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Description
Our TableValuedExpression currently accepts scalar parameters only (SqlExpression). However, we have some cases where we need to pass non-scalars. For example, SQL Server's VECTOR_DISTANCE() accepts a table expression - including alias:
SELECT TOP (10) s.id,
s.title,
r.distance
FROM VECTOR_SEARCH(
TABLE = dbo.sessions AS s,
COLUMN = embedding,
SIMILAR_TO = @qv,
METRIC = 'cosine',
TOP_N = 10
) AS r
WHERE accepted = 1
ORDER BY r.distance;Similarly, FREETEXTTABLE():
SELECT FT_TBL.Description
,KEY_TBL.RANK
FROM Production.ProductDescription AS FT_TBL
INNER JOIN FREETEXTTABLE(Production.ProductDescription,
Description,
'high level of performance',
LANGUAGE N'English', 2) AS KEY_TBL
ON FT_TBL.ProductDescriptionID = KEY_TBL.[KEY]
ORDER BY RANK DESC; Outside of SQL Server usage is probably quite limited; PostgreSQL has json_populate_recordset(), which accepts any record/composite type. Though it's unclear as of yet whether these would be considered scalars or not, If/when we implement support for records/composites.
In any case, there seems to be no harm in relaxing the parameter type; note that any code currently passing SqlExpression continues to work - we've just relaxed the accepted parameter type (this is potentially a provider-facing binary break, but very low-impact).