PostgreSQL range type and functions

[Rafael Barbaresco]

Hello.

I'd like to contribute to H2 and implement support for PostgreSQL range types and operators. Would such features be accepted in the main branch or would I have to make it third party?

Range Types: https://www.postgresql.org/docs/current/rangetypes.html
Range Functions and Operators: https://www.postgresql.org/docs/current/functions-range.html

Regards,
Rafael Barbaresco

[Evgenij Ryazanov]

Hello.

I think it would be better to implement UDTs from the SQL Standard instead of non-standard and not compatible with anything feature of another DBMS with esoteric syntax.

Contributions with non-standard operators most likely will be rejected, we don't want to have all this mess in H2.

So the main question is what exactly do you want? Do you want to have full syntax compatibility with PostgreSQL or you simply want to have some representation of these values?

[Noel Grandin]

Compatibility with PostgreSQL is ok, IMO, because it's a major open-source engine.

And as long as someone else is doing the work, I'm not opposed to accepting such contributions.

Yeah, it's a little icky in the parsing code, but as long as it's only active in PostgreSQL compat mode, that's fine by me.

For me, it depends on how deep you want the compatibility to go - surface level compatibility is fine, but deep
compatibility that requires adding extra paths through other more important data structures would be a stretch.

[Evgenij Ryazanov]

New data types will definitely require massive changes everywhere.

I mentioned UDTs because their implementation may significantly reduce impact and complexity of such compatibility features, but we don't have them yet.

[Noel Grandin]

On 2021/02/19 9:27 am, Evgenij Ryazanov wrote:
> New data types will definitely require massive changes everywhere.
>

Yup, that's what I meant by deep vs shallow integration.

If the new datatypes are just aliases over existing types, it's not a problem.

If the new datatypes want proper compatibility with PostgeSQL, then we would have to see how much compat we can supply
before we draw the line and say "this is too disruptive".

On the up side, such new datatypes would give us an initial idea of the requirements for UDTs.

And I dont think we need to follow the SQL-Standard design for UDTs - nobody else does.