Re: [hibernate-team] PostgreSQLDialect

On Nov 12, 2007 10:55 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> I've posted files to pgsql-patches, as well as to Diego directly.

I dropped them into a Hibernate 3.2.5.ga source tree and ran the
hibernate tests with the 8.3 dialect against pgsql HEAD and got a few
errors. Diego, I assume that the hibernate tests are in a state where
we expect them to all pass? I didn't bother trying the original
dialect that hibernate shipped with, so I'm not sure if it passes or
not. Given that these seem like an improvement, I'll assume not.

> There are 3 files
> PostgreSQL8Dialect.java which implements enough for 8.0 and 8.1
> PostgreSQL82Dialect.java which extends PostgreSQL8Dialect
> PostgreSQL83Dialect.java which extends PostgreSQL8Dialect

Given that our releases are generally a feature superset of previous
ones, should we just make PostgreSQL83Dialect extend
PostgreSQL82Dialect? I note that atm they are identical. Or does that
offend anyone's delicate OO sensibilities?

> We can then push out a new file every release.

Yes, I like the general approach.

> - GUID support is possible, but really opens up the debate about how
> extensibility features should be handled.

Yeah. Should the GUID be mapped to e.g. java.util.UUID? Or just
string? etc. I had some thoughts about enums, but if someone's using
the annotation stuff (either JPA or hibernate specific) then they
already have a mechanism to map between a Java enum and a string, so
the only thing that wouldn't work would be DDL generation, since
hibernate wouldn't understand the necessaary CREATE TYPE commands.

> - For now, I think we should document the procedure for adding a local
> site Dialect which implements additional functions, with GUID as an
> example

Oh, were you just referring to making GUID functions available? Yeah
that shouldn't be too hard, but again I wonder if we should look at an
automatic way to generate those function declarations. Given that the
dialect can't read the database when it's instantiated, perhaps the
way to go would be to ship a resource file containing the expected
functions and have the dialect parse that before calling the
registration functions. There would then be a process that a user
could run against their own database to regenerate that file, and
they'd just need to drop it into their classpath for it to be picked
up.

All of this should work for functions, but operators are a whole
different story. I strongly suspect that someone is not going to be
able to use e.g. @@ in a HQL query. Are there ways to do tsearch type
queries just using functions and more standard operators?

Cheers

Tom