Added oids_of! macro

[YohDeadfall]

That's an improvement for SPI making it less cumbersome. Just to feel the difference look at the tests. Who would really want to write something like PgBuiltInOids::INT4OID.oid() instead of just telling a Rust type?

I will change the behavior of this macro a bit when you will be ready for shipping 0.13, so it won't produce any vector but a slice.

[workingjubilee]

I don't think this should include a vec![] when it could instead be invoked as vec![oids_of!(...)]

this would allow constructing arrays also, or other structures.

[YohDeadfall]

Yes, that's the plan when I get rid of Option<Vec<PgOid>> because now it's too wordy.

[workingjubilee]

...if that's the plan, then?

[YohDeadfall]

Yeah, I will remove vec! from here and will change the methods of SpiClient to use slices as soon as you that the breaking change time has come (:

[workingjubilee]

I'd rather not add this then just break it again.

[YohDeadfall]

Let it be non-breaking then.

[workingjubilee]

I don't think this has the right semantics right now. It's not clear to me that oids_of!() should be an InvalidOid, instead of, say, a compile-time error. Or an empty array.

[workingjubilee]

I think we should ship a non-plural oid_of! (I'd prefer an fn if we can swing it, tbh, but I'll settle) first and tinker with it a bit before jumping to generating arrays.

[YohDeadfall]

If something isn't an IntoDatum then a compiler error will appear, so the value of each element purely depends on the implementation of each type used there. InvalidOid is just to make an empty version of oids_of! to be strongly typed and not to depend on the context.

Let's say, I don't want oids_of! to give you an empty array of integers like in the following case:

let _: &[i32] = oids_of![];

That's why there's [$crate::pg_sys::PgOid::Invalid; 0].

[YohDeadfall]

I think we should ship a non-plural oid_of!

You have it already, IntoDatum::type_oid(), and it's a function. I thought about making a non-plural version of the macro, but I see no real use case for it.

[workingjubilee]

tbh, that's kind of the problem.

A macro creates a false impression this will resolve statically.

That fn produces runtime lookups.

[YohDeadfall]

It depends, actually. For built-in types, it's static, but for custom types it isn't.

[workingjubilee]

I realize that for the existing inputs, it's somewhat incoherent to use. But the reason to make it a zero-sized array, effectively, is to make a macro-call to it... possibly itself from a macro-expansion... valid anywhere we ask for &[pg_sys::Oid], without having to reason about the exact input. For a given input, sure, they might need to do something like

let oids = oids_of![$($types,)];
oids.is_empty().then_some(&oids)

but this enables that.

Basically, we shouldn't overfit it to the existing use-cases.

[YohDeadfall]

Sorry, not following. Could you reword it a bit so I can get what I should do?