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

Figure out what people actually use derive(PostgresType) for #1384

Open
2 of 6 tasks
workingjubilee opened this issue Nov 8, 2023 · 3 comments
Open
2 of 6 tasks

Figure out what people actually use derive(PostgresType) for #1384

workingjubilee opened this issue Nov 8, 2023 · 3 comments
Labels

Comments

@workingjubilee
Copy link
Member

workingjubilee commented Nov 8, 2023

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

Footnotes

  1. https://github.com/pgcentralfoundation/pgrx/pull/1381

@workingjubilee
Copy link
Member Author

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

@workingjubilee
Copy link
Member Author

workingjubilee commented Nov 8, 2023

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.

@eeeebbbbrrrr
Copy link
Contributor

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.

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

2 participants