Support .toPostgres() on Array-derived objects

[mordae]

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]

Code is not correct or tested. Also, inheriting from Array is pretty niche, creating Array.prototype.toPostgres is a really bad idea, and the existing alternatives to achieve the same goal (global or one-off custom serialization functions) seem pretty good to me.

[mordae]

@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.

[charmander]

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.

[mordae]

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.