brianc
Support .toPostgres() on Array-derived objects
Related to #2012.
Since we cannot disambiguate between Arrays that should be converted to PostgreSQL array types and Arrays that should be treated as JSON, make it at least possible to define custom Array-derived types.
This also makes it possible to properly serialize Array-derived multirange collections where elements must not be independently escaped.
@charmander I don't follow. How is the condition incorrect? In the sole case of Array instance with toPostgres method it falls through and gets prepared as other objects with toPostgres method.
Regardless of your judgement on goodness or badness of extending built-in prototypes, users are going to, when they need to. This change just makes toPostgres handling uniform for all "objects" like one would expect it to be.
You were right about Array subclassing being... niche... Or rather utterly broken. TIL.
How is the condition incorrect?
It’s missing typeof.
Regardless of your judgement on goodness or badness of extending built-in prototypes, users are going to, when they need to.
Well, users can’t do that in this case because we don’t currently support it, and I’m making an argument against adding support for it.
How is the condition incorrect?
It’s missing
typeof.
🤦♂️ thanks. I must have been asleep. Will fix.
Regardless of your judgement on goodness or badness of extending built-in prototypes, users are going to, when they need to.
Well, users can’t do that in this case because we don’t currently support it, and I’m making an argument against adding support for it.
If you see the linked issue, users have been doing exactly that by modifying the method on the fly.
But OK, if you disagree, feel free to close the issue. This was preferable solution for me, but I can probably solve my use case in other ways or apply the patch locally.