-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Support .toPostgres() on Array-derived objects #3360
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Related to brianc#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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@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.
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.