New sql type mapping

[Hoverbear]

This revamps the SQL type mapping system to be based around the trait SqlTranslatable instead of the current TypeId based system.

Releasing this has breaking changes and requires a 0.5.0

What's changed

• pgx is now able to map Rust types to SQL based on the existence of an SqlTranslatable trait (and its results). This trait is implemented for all types pgx supports, and implementations are generated in #[derive(PostgresType)] and #[derive(PostgresEnum)] macros for users.
• Foundation added to handle const generics for tasks such as supporting NUMERIC(1, 10).
• Foundation added for generic types for tasks such as supporting users returning Result<T,E> once codegen is updated.
• The pgx-utils/src/rewriter.rs itemfn code was mostly migrated into the sql_entity_graph code and integrated.
• Source-only SQL mapping still exists and happens, however @workingjubilee and I discussed that there was a way to get this working with a newtype pattern. This was left for the future.
• SQL generation is, in general, quite a bit more strict about how it works, and users should see more, earlier build time errors when they try to do things that won't work.

Breaking changes

• We no longer maintain a big hashmap of "Rust type -> SQL type" for builtin types like i32 and char which is passed around during the SQL generation process. The pgx_graph_magic!() (and thus pgx_module_magic!()) macros have had their ABIs changed. Old version of cargo-pgx won't work anymore.
• It is no longer possible to return impl Iterator<Item = ...> from #[pg_extern]s. Instead, we have SetOfIterator<'a, T> and TableIterator<'a, T> which generate SETOF T and TABLE T in SQL generation respectively.
  • Users can transform set returning functions from:

    fn fluffy() -> impl Iterator<Item = i32> {
       vec![1,2,3].into_iter()
    }

    Into:

    fn fluffy() -> SetOfIterator<'static, i32> {
       SetOfIterator::new(vec![1,2,3].into_iter())
    }

  • Users can transform table returning functions from:

    fn fluffy() -> impl Iterator<Item = (named!(name, String), named!(i32),)> {
       vec![1,2,3].into_iter()
    }

    Into:

    fn fluffy() -> TableIterator<'static, (named!(name, String), named!(i32),)> {
       TableIterator::new(vec![1,2,3].into_iter())
    }

  • If your function accepts some borrows with lifetimes, it may need to use those lifetimes instead of 'static.

[workingjubilee]

@Hoverbear Alright. I now have this building both ZomboDB and <REDACTED>, and the latter's tests even all pass. Less sure about ZomboDB, some do, some probably weren't set up correctly in my env, but also that has a slower release cadence and so we can probably defer the ZomboDB release if we need to fix bugs.

[workingjubilee]

This PR will now also fix #615.

[workingjubilee]

Apparently this now works for ZomboDB on build environments that aren't my local? I have no idea what's going wrong on my local. I can fix it later if necessary.

[workingjubilee]

Okay, so there are a few lingering test errors at zombodb/zombodb#763 but

[3:02 PM] Hoverbear: I want to look at the timestamp thing
[3:04 PM] Hoverbear: Hmmm yes it looks fine
[3:04 PM] Hoverbear: I think it's just a serde thing
[3:04 PM] Hoverbear: Okay I feel comfortable-ish with the pgx new-type-mapping pr merging
[3:05 PM] Hoverbear: If you wanna, go ahead ❤️

These errors were likely introduced by #643 which otherwise we expect to have significant performance/correctness improvements from, so we are not reverting that (but we might be adjusting the serialization slightly). Otherwise we're good, it looks like.

[Hoverbear]

Yay!

[Hoverbear]

We noticed this seems to have missed some dead code at https://github.com/tcdi/pgx/blob/cafefaaf8810143059f7e731e6cd464a38499c6a/pgx/src/lib.rs#L156

[workingjubilee]

Opened #697