Skip to content
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

Correct way to interpret row data when implementing custom postgres types? #1832

Closed
Boscop opened this issue Sep 2, 2018 · 2 comments
Closed

Comments

@Boscop
Copy link

Boscop commented Sep 2, 2018

What is the correct way to interpret row data when implementing custom postgres types?

Diesel seems to use the binary protocol but how are geography points encoded in the binary protocol?

I'm trying to figure out how to get geography points working, are my assumptions correct here?
ThinkAlexandria/diesel_geometry#7 (comment)

When I convert the first 8 bytes of the EWKB string in reversed byte order to a f64, it shows a different value than what PgPoint shows as the first coordinate..

@Boscop
Copy link
Author

Boscop commented Sep 2, 2018

Ah, I shouldn't reverse the byte order..
Now it shows the same value.


But now the question arises, what's the correct way to serialize geography points?

Is it valid to write geography points as EWKB in any expression? such as in insert statements, or as argument to functions like ST_DWithin?

@weiznich
Copy link
Member

weiznich commented Sep 2, 2018

I don't know the exact representation of every postgres type in libpq. This would be a better question for the libpq/postgis folks.
In general serialisation should just be the reverse operation of deserialisation, so just create the same thing you get FromSql::from_sql.

I close this issue because this is nothing actionable for diesel itself. (The representation is something that is defined by libpq/postgis)

@weiznich weiznich closed this as completed Sep 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants