Feature Request: pyformat param types

[chooban]

Describe the Feature
Would you consider adding support for pyformat param types? I've run a few of our snowsql scripts throught the formatter and for the most part it's absolutely fantastic, but it trips up on our param types which use, e.g. %(end_date)s.

I thought I should ask before even considering diving in and attempting a PR, in case it was something that had been previously considered and rejected.

Why do you want this feature?
This would increase the number of situations in which the tool could be used, and is expanding on an existing feature rather than adding something entirely new.

[nene]

It would be nice to support this kind of parameters, but I wouldn't really like to add a specific option for this Python formatting syntax. Rather I would consider providing a more flexible way of customizing the possible parameter types.

But I'm not fully sure what would be the best API for this. Currently the paramTypes setting categorizes parameters to 4 types:

• positional (?)
• numbered (like :1)
• named (like :name)
• quoted (like :"name")

This Python syntax looks most similar to the quoted type, with parenthesis sort-of used for quoting, plus there's this extra s code at the end (which I understand can be a lot more complex than just a single letter). But we can't simply add another quote type that would match (name)s part as that would most likely interfere with parsing of parenthesis pairs.

Assuming these pyformat parameters can be parsed with regular expressions, the syntax could be something like:

paramTypes: {
  custom: [
    { regex: String.raw`%\((\w+)\)[a-z]` }
  ]
}

Additional consideration is that we also need a way to determine the actual name inside the parenthesis. This is used by the parameter-substitution feature. A simplest approach would be to just use a regex capture group as I've done above.

[chooban]

That would definitely be good for us, though it sounds like a bit of a bigger rewrite of the param code, unless it's already using regex behind the scenes.

[nene]

Well, it is indeed using regexes behind the scenes. It's more about how the final regexes for matching parameter tokens get built.

[nene]

Related discussion: #551

[nene]

This is now implemented in 12.2.0