Happy to work on adding this feature, for at least a subset of the most useful options. (Such as not lower casing by default.)
Of course, postgres function semantics make situations like this a challenge, so before I launch on it, I'd like an opinion on how best to do it. What I'm thinking is an optional second argument that is a text array of boolean-like values structured as 'option' or 'no_option', so for example:
SELECT postal_normalize('123 Main St', ['no_strip_accents', 'no_lowercase', 'replace_numeric_hyphens'])
This does not handle all possible options accepted by libpostal, like the address_components or languages options, but we can handle that separately.
Maybe we should go all-in on the jsonb thing and pass the options as a json key/value? We have some magic-string options in ST_Buffer and they require a surprising amount of parsing and validation logic. Price we pay, I guess.
Happy to work on adding this feature, for at least a subset of the most useful options. (Such as not lower casing by default.)
Of course, postgres function semantics make situations like this a challenge, so before I launch on it, I'd like an opinion on how best to do it. What I'm thinking is an optional second argument that is a text array of boolean-like values structured as 'option' or 'no_option', so for example:
SELECT postal_normalize('123 Main St', ['no_strip_accents', 'no_lowercase', 'replace_numeric_hyphens'])
This does not handle all possible options accepted by libpostal, like the
address_components
orlanguages
options, but we can handle that separately.Opinions?