Re: [hibernate-team] PostgreSQLDialect - Mailing list pgsql-hackers

On Mon, 2007-11-12 at 13:30 +0000, Tom Dunstan wrote:
> On Nov 12, 2007 10:55 AM, Simon Riggs <simon@2ndquadrant.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.

It's possible I caused some, though the largest single change was the
reordering, which was necessary to check off everything.

I was assuming your CLOB/BLOB changes would go in too. 

> > 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?

I'm easy either way. That's the way I started, FWIW, I just foresaw this
long list of dependencies and switched back to the two level structure.

> > - 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.

The Dialect says "command to select GUID from underlying database". No
real reason to get one from there.

Hibernate doesn't support a specific GUID type since
getSelectGUIDString() returns String, so I guess DB support for GUIDs is
irrelevant.

So OK, java.util.UUID sounds OK so far, anyone else?

> > - 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.

I like that.

> 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?

Hmmmm...

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com