On Mon, Dec 6, 2010 at 7:49 PM, Craig Ringer
<craig@postnewspapers.com.au> wrote:
> Hi all
>
> I'm finding a few areas where PostgreSQL's refusal to implicitly cast
> from 'text' to another type is causing real problems, particularly when
> using the PgJDBC driver. I'd like to propose a couple of relaxations of
> the implicit cast rules for certain text-like types:
>
> - user-defined enums; and
> - xml
>
> ('json' should also be castable from text when introduced).
>
> Why? Because client interfaces don't always know about the Pg-specific
> types. They can use text-like types just fine if they can use text-typed
> parameters when inserting/updating them. I feel that PostgreSQL is
> overzealous to the point of being counterproductive by refusing to
> implicitly cast these types, as they are subject to validation by the
> input function in any case.
>
> Can anybody show me a case where permitting implicit casts from text for
> enums, xml or json types might introduce an error or cause SQL with a
> mistake in it to execute instead of failing when it should?
>
> This is driving me nuts when working with PgJDBC via various ORM layers
> (I know, I know, but they're life at this point) that would work happily
> with these types if they were implicitly castable to/from strings, but
> don't understand how to explicitly specify these postgresql-specific
> types when talking to the JDBC layer.
I totally must +1 for this idea, especially for ENUMs. It was a
complete nightmare getting nHibernate to map a Postgres ENUM to a C#
Enum automatically. I had to hack around all sorts of things. mostly
because the SQL syntax would assume the data was a string.