With three database engines supported in core, and more supported in contrib, we need to determine and document the list of functions and operators that Drupal supports.

I started a handbook page, feedback is welcome.

I suggest we adopt the following constraints:

  • When possible, limit support to functions supported in MySQL and PostgreSQL, in their more common form
  • Support only the forms with a fixed-number of arguments, and do not support optional arguments: it is not possible to create a user-defined function with variable-number of arguments or optional arguments in most database engines
  • Always document the expected input types and the return type. Only support undefined types on input, not on output as it causes issues down the road

Comments

marcvangend’s picture

Thanks, this is a valuable addition to the documentation.

What if I would need a function or operator that is not listed? Maybe this documentation page could also answer that question.

PS. I'm not sure if this issue should be 'critical'.

damien tournoud’s picture

@marcvangend: it is not a critical *bug*, but really a critical task we have to do before Drupal 7 is out of the corner. It is currently not possible to completely implement a new database driver because the specification is far from being clear enough.

Crell’s picture

Priority: Critical » Normal

I disagree that this is critical. Clearly people have been able to write additional drivers without this list, and writing new drivers is a very edge case, so it's not a release blocker for Drupal 7 itself. That said, yes we should document what the "lowest common denominator" of SQL syntax itself is. That's not a question of DBTNG supporting it though; it's just documenting what the LCD is between the databases we officially support.

Status: Active » Closed (outdated)

Automatically closed because Drupal 7 security and bugfix support has ended as of 5 January 2025. If the issue verifiably applies to later versions, please reopen with details and update the version.