Fix(Postgres): Support UNNEST

[vegarsti]

Fixes #1760.

[georgesittas]

Is it possible to just map UNNEST to exp.Explode for postgres and make sure to rename it @ generation time? I think this would remove the need to add all this custom logic to also handle exp.Unnest.

[vegarsti]

Can't we just map UNNEST to exp.Explode for postgres and make sure to rename it @ generation time? I think this would remove the need to add all this custom logic to also handle exp.Unnest

Oh, interesting, will try that!

[vegarsti]

exp.Explode takes a this while exp.Unnest takes an expressions, though, does that matter? How does the mapping/renaming work?

[georgesittas]

How does the mapping/renaming work?

You have to map "UNNEST" to exp.Explode.from_arg_list in Postgres.Parser.FUNCTIONS and then add an entry in Postgres.Generator.TRANSFORMS to map exp.Explode to rename_func("UNNEST").

[vegarsti]

How does the mapping/renaming work?

You have to map "UNNEST" to exp.Explode.from_arg_list in Postgres.Parser.FUNCTIONS and then add an entry in Postgres.Generator.TRANSFORMS to map exp.Explode to rename_func("UNNEST").

Thanks!

[vegarsti]

@georgesittas That was neat! Thanks for the explanation.

[georgesittas]

Looks way cleaner :)

[georgesittas]

Ah I just noticed something in postgres's docs: UNNEST can actually receive >1 arguments. With this approach we'll crash if we get the following query (from the doc page):

SELECT * FROM UNNEST(ARRAY[1,2], ARRAY['foo','bar','baz']) AS x(a,b)

So this is actually breaking, because before we'd just parse this into an exp.Anonymous without problems. Maybe we can simply allow >1 args in exp.Explode, in order to also keep the solution here simple?

cc: @tobymao

[tobymao]

sure, please fix

[vegarsti]

Ah I just noticed something in postgres's docs: UNNEST can actually receive >1 arguments. With this approach we'll crash if we get the following query (from the doc page):

SELECT * FROM UNNEST(ARRAY[1,2], ARRAY['foo','bar','baz']) AS x(a,b)

So this is actually breaking, because before we'd just parse this into an exp.Anonymous without problems. Maybe we can simply allow >1 args in exp.Explode, in order to also keep the solution here simple?

cc: @tobymao

Ah, good catch! What does it entail to let it take more than one argument? Changing explode from having "this" to "expressions"?

I won't have time to do that tonight, so feel free to do it if you have time. Otherwise happy to try tomorrow!

[georgesittas]

No worries, I'll play around with it locally and let you know when I have something.

[georgesittas]

Ha, this is actually already taken care of -- there might be no problem with this approach!

• Postgres docs mention that the multi-argument form is only allowed in a query's FROM clause.
• In the definition of _parse_table we try to parse an UNNEST expression before hitting the function parser:

    def _parse_table(
        self, schema: bool = False, alias_tokens: t.Optional[t.Collection[TokenType]] = None
    ) -> t.Optional[exp.Expression]:
        lateral = self._parse_lateral()
        if lateral:
            return lateral

        unnest = self._parse_unnest()
        if unnest:
            return unnest
        ...

This means that with this PR the parsing of multi-argument UNNEST expressions doesn't break for Postgres:

>>> import sqlglot
>>> sqlglot.parse_one("SELECT * FROM UNNEST(ARRAY[1, 2], ARRAY['foo', 'bar', 'baz']) AS x(a, b)")
(SELECT expressions:
  (STAR ), from:
  (FROM this:
    (UNNEST expressions:
      (ARRAY expressions:
        (LITERAL this: 1, is_string: False),
        (LITERAL this: 2, is_string: False)),
      (ARRAY expressions:
        (LITERAL this: foo, is_string: True),
        (LITERAL this: bar, is_string: True),
        (LITERAL this: baz, is_string: True)), alias:
      (TABLEALIAS this:
        (IDENTIFIER this: x, quoted: False), columns:
        (IDENTIFIER this: a, quoted: False),
        (IDENTIFIER this: b, quoted: False)))))
>>> sqlglot.parse_one("SELECT UNNEST(c) FROM t", "postgres")
(SELECT expressions:
  (EXPLODE this:
    (COLUMN this:
      (IDENTIFIER this: c, quoted: False))), from:
  (FROM this:
    (TABLE this:
      (IDENTIFIER this: t, quoted: False))))

There's only a (minor) issue, where UNNESTs in the FROM clause are represented as exp.Unnest nodes, whereas single-argument UNNESTs anywhere else are represented as exp.Explode nodes. If we don't mind having this disparity (in return for simplifying the transformation proposed here), then this PR is good to go.

Note: added a couple more tests.