File: dialects.rst

package info (click to toggle)
sqlfluff 3.5.0-1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 33,984 kB
  • sloc: python: 106,138; sql: 34,188; makefile: 52; sh: 8
file content (48 lines) | stat: -rw-r--r-- 2,099 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
.. _dialectref:

Dialects Reference
==================

SQLFluff is designed to be flexible in supporting a variety of dialects.
Not all potential dialects are supported so far, but several have been
implemented by the community. Below are a list of the currently available
dialects. Each inherits from another, up to the root `ansi` dialect.

For a canonical list of supported dialects, run the
:program:`sqlfluff dialects` command, which will output a list of the
current dialects available on your installation of SQLFluff.

.. note::

    For technical users looking to add new dialects or add new features
    to existing ones, the dependent nature of how dialects have been
    implemented is to try and reduce the amount of repetition in how
    different elements are defined. As an example, when we say that
    the :ref:`redshift_dialect_ref` dialect *inherits* from the
    :ref:`postgres_dialect_ref` dialect this is not because there
    is an agreement between those projects which means that features
    in one must end up in the other, but that the design of the
    :ref:`redshift_dialect_ref` dialect was heavily *inspired* by the
    postgres dialect and therefore when defining the dialect within
    sqlfuff it makes sense to use :ref:`postgres_dialect_ref` as a
    starting point rather than starting from scratch.

    Consider when adding new features to a dialect:

    - Should I be adding it just to this dialect, or adding it to
      a *parent* dialect?
    - If I'm creating a new dialect, which dialect would be best to
      inherit from?
    - Will the feature I'm adding break any *downstream* dependencies
      within dialects which inherit from this one?

.. We define a shortcut to render double backticks here, which can
   then be referenced by individual dialects when they want to say
   how backtick quotes behave in that dialect. They would otherwise
   be interpreted as markup and so not shown as back quotes.

.. |back_quotes| raw:: html

    <code class="code docutils literal notranslate">``</code>

.. include:: ../_partials/dialect_summaries.rst