Blog· Tested on ClickHouse 26.4

Functions that exist but system.functions cannot see

I expected every built-in function to be listed in system.functions. Some aliases got registered in 23.4; date_add and timestamp_add still are not, because they only exist in the parser.

Source: github.com

I expected every callable function to be listed in system.functions, the catalogue editors, linters and doc generators read. I hit a counter-example writing a query with date_add and timestamp_sub: both work when called and were absent from the table. I asked for it to be made complete.

A maintainer first explained that date_add and timestamp_add are aliases of plus, and timestamp_sub of minus; I answered that documented names should still be discoverable. Then rschu1ze found a whole category of the same problem: in the parser’s getFunctionLayer() there are functions and aliases that never reach the function registry. PR #48489 (“Register datediff and trim aliases in system.functions”), merged 2023-04-11 and shipped in 23.4, registered the ones that could be, and closed the issue.

He was explicit that date_add, timestamp_add and their relatives were not among them: they exist only in the parser, with no function behind them to alias, and a separate factory for such names “would be quite ugly”. Status: partially implemented.

Checked on 26.4, the registered aliases show up with their targets (date_diff to dateDiff, trim to trimBoth, ltrim to trimLeft), while a search for date_add, timestamp_add or timestamp_sub returns no rows. The parser rewrites them before the function layer sees them:

EXPLAIN SYNTAX SELECT date_add(DAY, 1, toDate('2024-01-01'));
-- SELECT plus(toDate('2024-01-01'), toIntervalDay(1)) FROM system.one

Any tool that trusts system.functions will mark them unknown. The same gap exists for table engines.

feature-requestsystem-tablesfunctions

Discussion

Comments live in GitHub Discussions. Sign in with GitHub to join in.