Dots in type names cause parse error

[skreborn]

Dots in type names, while uncommon and generally advised against, are perfectly valid. PostgreSQL allows using quotation marks to escape names containing otherwise illegal characters.

As this is a clearly uncommon edge case, I didn't actually expect this to work, but I believe it should not be a difficult issue to fix either.

What works

Type definitions like the following work flawlessly as-is.

--: bar(a?, b?)

-- Should be translated to "bar"

What does not

But adding a dot in the name...

--: foo.bar(a?, b?)

-- Should be translated to "foo.bar"

...results in a parse error.

--- stderr
Error: Couldn't parse queries

[skreborn]

Actually, giving it further thought; we probably should just allow using quoted strings wherever identifiers are expected to handle all of these cases in one fell swoop. Cornucopia needs not translate or change the quotation on names, just let them exist in peace.

With that, all of these would be perfectly valid, while the original foo.bar (without quotes) would still throw an error. This helps avoid confusion and matches PostgreSQL behavior.

--: bar(a?, b?)
--: "bar"(a?, "b.c"?)
--: "foo.bar"(a?, b?)

[skreborn]

I've started work on a PR to resolve this.

[skreborn]

Created #185.