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
in order to support a new postgres type, there must be an agreement on which javascript structure will hold the data.
for floats, I chose the ieee754 module. For other types, native javascript types were ok.
For uuid, it could be a string like "a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11" or an array of UInt8Array[16] or a buffer.
Each choice has pros/cons.
In the PR #19 it is proposed that the uuid type should be represented in memory as a javascript string.
I would like to have more information on the use case for this because the type impedance (buffer // string) can have a real cost when it is applied on each and every uuid field of all the rows of a table.
I think the uuid are rarely modified so is the string representation really needed or is it just unnecessary work in a buffer=>string=>buffer scenario ?
No description provided.
The text was updated successfully, but these errors were encountered: