Skip to content

How strict should ToSql and FromSql be? #14

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

Closed
sfackler opened this issue Aug 27, 2013 · 1 comment
Closed

How strict should ToSql and FromSql be? #14

sfackler opened this issue Aug 27, 2013 · 1 comment
Labels

Comments

@sfackler
Copy link
Owner

This will become much more relevant when issue #7 is implemented. FromSql for float may have to be able to deal with numerous kinds of integer binary data if we want to be forgiving about conversions.

@sfackler
Copy link
Owner Author

sfackler commented Sep 1, 2013

I'm leaning towards making both ToSql and FromSql strict. An i32 value maps to and from an INT value, f32 values map to and from REAL, etc. Supporting #7 is otherwise an enormous pain since the backend tells the frontend what types it expects to receive and will return. This will require a reasonable API to expose the types of parameters and results to support dealing with types that aren't known ahead of time to the programmer.

sfackler added a commit that referenced this issue Sep 2, 2013
sfackler added a commit that referenced this issue Sep 2, 2013
The set of types the driver asks for in binary format is currently hard
coded.

cc #7, #14
@sfackler sfackler closed this as completed Sep 2, 2013
pimeys pushed a commit to grafbase/rust-postgres that referenced this issue Oct 12, 2023
Add query_raw_txt client method

It takes all the extended protocol params as text and passes them to
postgres to sort out types. With that we can avoid situations when
postgres derived different type compared to what was passed in arguments.
There is also propare_typed method, but since we receive data in text
format anyway it makes more sense to avoid dealing with types in params.

This way we also can save on roundtrip and send Parse+Bind+Describe+Execute
right away without waiting for params description before Bind.

Use text protocol for responses -- that allows to grab
postgres-provided serializations for types.

Catch command tag.

Expose row buffer size and add `max_backend_message_size` option to
prevent handling and storing in memory large messages from the backend.

Co-authored-by: Arthur Petukhovsky <[email protected]>
pimeys pushed a commit to grafbase/rust-postgres that referenced this issue Oct 13, 2023
Add query_raw_txt client method

It takes all the extended protocol params as text and passes them to
postgres to sort out types. With that we can avoid situations when
postgres derived different type compared to what was passed in arguments.
There is also propare_typed method, but since we receive data in text
format anyway it makes more sense to avoid dealing with types in params.

This way we also can save on roundtrip and send Parse+Bind+Describe+Execute
right away without waiting for params description before Bind.

Use text protocol for responses -- that allows to grab
postgres-provided serializations for types.

Catch command tag.

Expose row buffer size and add `max_backend_message_size` option to
prevent handling and storing in memory large messages from the backend.

Co-authored-by: Arthur Petukhovsky <[email protected]>
pimeys pushed a commit to grafbase/rust-postgres that referenced this issue Nov 27, 2023
Add query_raw_txt client method

It takes all the extended protocol params as text and passes them to
postgres to sort out types. With that we can avoid situations when
postgres derived different type compared to what was passed in arguments.
There is also propare_typed method, but since we receive data in text
format anyway it makes more sense to avoid dealing with types in params.

This way we also can save on roundtrip and send Parse+Bind+Describe+Execute
right away without waiting for params description before Bind.

Use text protocol for responses -- that allows to grab
postgres-provided serializations for types.

Catch command tag.

Expose row buffer size and add `max_backend_message_size` option to
prevent handling and storing in memory large messages from the backend.

Co-authored-by: Arthur Petukhovsky <[email protected]>
jakubadamw pushed a commit to grafbase/rust-postgres that referenced this issue Mar 4, 2024
Add query_raw_txt client method

It takes all the extended protocol params as text and passes them to
postgres to sort out types. With that we can avoid situations when
postgres derived different type compared to what was passed in arguments.
There is also propare_typed method, but since we receive data in text
format anyway it makes more sense to avoid dealing with types in params.

This way we also can save on roundtrip and send Parse+Bind+Describe+Execute
right away without waiting for params description before Bind.

Use text protocol for responses -- that allows to grab
postgres-provided serializations for types.

Catch command tag.

Expose row buffer size and add `max_backend_message_size` option to
prevent handling and storing in memory large messages from the backend.

Co-authored-by: Arthur Petukhovsky <[email protected]>
jakubadamw pushed a commit to grafbase/rust-postgres that referenced this issue Mar 23, 2024
Add query_raw_txt client method

It takes all the extended protocol params as text and passes them to
postgres to sort out types. With that we can avoid situations when
postgres derived different type compared to what was passed in arguments.
There is also propare_typed method, but since we receive data in text
format anyway it makes more sense to avoid dealing with types in params.

This way we also can save on roundtrip and send Parse+Bind+Describe+Execute
right away without waiting for params description before Bind.

Use text protocol for responses -- that allows to grab
postgres-provided serializations for types.

Catch command tag.

Expose row buffer size and add `max_backend_message_size` option to
prevent handling and storing in memory large messages from the backend.

Co-authored-by: Arthur Petukhovsky <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant