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
A lot of programmers using pgrx seem to think derive(PostgresType) is required for some things. However, they aren't very clear on what those things are. For instance, they also think derive(Serialize, Deserialize) is required for implementing FromDatum and IntoDatum, but it is not! You can implement those by hand. My PR1 does propose to do away with that ability, leaving a gap for those who do use by-hand implementations that we should close before releasing 0.12.0.
Frankly, I myself am not entirely sure what derive(PostgresType) is actually... for? Not because I can't read the code, but because it does a lot of small things, currently, which are seemingly-needlessly coupled. I don't know which one was the "main point". It would be nice if we could work out a more consistent story for it.
We need
to figure out everything PostgresType does
it emits DDL for CREATE TYPE
it potentially implements JsonInOutFuncs
it potentially implements PgVarlenaInOutFuncs
it potentially implements FromDatum and IntoDatum
it may be overridden by InOutFuncs
it emits a bunch of #[pg_extern] functions for each of these cases
to figure out what parts of PostgresType do actually need to be coupled
to figure out if there's any use-cases we're missing
a substitute for derive(PostgresType) + impl {From,Into}Datum (sortof)
a substitute for derive(PostgresType) + impl InOutFuncs
a substitute for derive(PostgresType) + impl InOutFuncs + impl {From,Into}Datum
We don't necessarily need to address all possible concerns here but we would need to figure out enough that the 0.12.0 migration becomes possible for our extant users if we accept #1381
Okay, so the primary effect of derive(PostgresType) is that it emits CREATE TYPE DDL, which is otherwise more annoying to handle correctly, as it requires knowing SQL in order to correctly write it and comes with implicit unsafe obligations. It's important that programmers not be expected to know both Rust and SQL AND the nuances of Postgres in order to use pgrx.
Okay, so the primary effect of derive(PostgresType) is that it emits CREATE TYPE DDL.
It also emits a ton of code, including FromDatum/IntoDatum impls and some of the Postgres type support functions for the text representation of the type-as-a-value.
A lot of programmers using pgrx seem to think
derive(PostgresType)
is required for some things. However, they aren't very clear on what those things are. For instance, they also thinkderive(Serialize, Deserialize)
is required for implementing FromDatum and IntoDatum, but it is not! You can implement those by hand. My PR1 does propose to do away with that ability, leaving a gap for those who do use by-hand implementations that we should close before releasing 0.12.0.Frankly, I myself am not entirely sure what
derive(PostgresType)
is actually... for? Not because I can't read the code, but because it does a lot of small things, currently, which are seemingly-needlessly coupled. I don't know which one was the "main point". It would be nice if we could work out a more consistent story for it.We need
#[pg_extern]
functions for each of these casesderive(PostgresType)
+impl {From,Into}Datum
(sortof)derive(PostgresType)
+impl InOutFuncs
derive(PostgresType)
+impl InOutFuncs
+impl {From,Into}Datum
Footnotes
https://github.com/pgcentralfoundation/pgrx/pull/1381 ↩
The text was updated successfully, but these errors were encountered: