You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello - author of node postgres here. Was reading your readme about not having clean hook points into the type parsing API. I implemented something for using parseFloat for numeric types here:
Similar to your module it adds some type deserialization back in. Maybe have a look there for how I handled it? Removes the burden of having to add the type parser manually to the consumer. I can definitely whip this up in a pull request for you if you want.
As far as the serialization part is concerned, I'm not sure how it would be possible to know when to serialize an object to an hstore value on the way in to the database? As far as I'm able to figure out node-postgres would have to query the metadata on the table & keep track of which columns were hstore and which were not so it would know when to serialize query parameters to hstore values. That's why there's no way to provide 'custom' serializers...they pretty much need to live in the consuming modules as far as I was able to reason.
The text was updated successfully, but these errors were encountered:
Hello - author of node postgres here. Was reading your readme about not having clean hook points into the type parsing API. I implemented something for using
parseFloat
for numeric types here:https://github.com/brianc/node-pg-parse-float
Similar to your module it adds some type deserialization back in. Maybe have a look there for how I handled it? Removes the burden of having to add the type parser manually to the consumer. I can definitely whip this up in a pull request for you if you want.
As far as the serialization part is concerned, I'm not sure how it would be possible to know when to serialize an object to an hstore value on the way in to the database? As far as I'm able to figure out node-postgres would have to query the metadata on the table & keep track of which columns were hstore and which were not so it would know when to serialize query parameters to hstore values. That's why there's no way to provide 'custom' serializers...they pretty much need to live in the consuming modules as far as I was able to reason.
The text was updated successfully, but these errors were encountered: