Skip to content

Some requests from my personal style #249

Description

@mmoncure

Love your project, requesting some new capabilities that would allow it to more easily bolt on to how I tend to write SQL.

  1. "Once only" option to FROM, JOIN WHERE, field list etc.

ok:
SELECT a
FROM foo;

SELECT a FROM foo;

SELECT
a,
b
FROM foo

not ok:
SELECT a, b
FROM foo;

SELECT a,b FROM foo, bar

  1. JOIN clause / ON aligned (also once only)

ok:
SELECT a
FROM foo
JOIN bar ON a=b

SELECT a
FROM foo
JOIN BAR ON
a = b
AND c=d

not ok:
SELECT a
FROM foo
JOIN bar
ON a=b

SELECT a
FROM foo
JOIN bar ON a=b AND c=d

  1. "once only" function calls: (this is typically 'warning only')

ok:
SELECT foo(a);
SELECT foo(
..a,
..b,
..c);

not ok:

select foo(a, b, c, d);

  1. primary clause alignment

SELECT ...
FROM ...
JOIN ...
WHERE ...
HAVING ..
LIMIT ..

not ok:
SELECT ....
..FROM
WHERE
....HAVING

  1. (extremely important!). left aligned from parenthesis, indentation alignment

SELECT ...
FROM
(

) ...

not ok:

SELECT ...
FROM
(
) ...

  1. aligned indentation always 2/4 space (stack on primary clause alignment role)

ok: (using . for space)
SELECT
..func(
....a,
....b)
FROM
(
..SELECT
..
..FROM
..(
....SELECT
..) q
) q
JOIN bar ON
..e = f
WHERE
..c = d

not ok: any non 2 space identation

Philosophy:
The basic philosophy is to separate primary from dependent clauses and use python-esque indentation for dependency. Leading parenthesis ok to be stacked as an alternate. This leads directly to readability IMO/
FROM (

)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions