Re: Type cast removal - proposed exceptions for xml,enum
От
Mike Christensen
Тема
Re: Type cast removal - proposed exceptions for xml,enum
Дата
Msg-id
AANLkTinO-qNjE6eJ0zxKGjYhfgg+YOMrrqZdptJf0c4D@mail.gmail.com
Ответ на
Type cast removal - proposed exceptions for xml,enum (Craig Ringer)
Список
Дерево обсуждения
Type cast removal - proposed exceptions for xml,enum Craig Ringer <craig@postnewspapers.com.au>
Re: Type cast removal - proposed exceptions for xml,enum Peter Eisentraut <peter_e@gmx.net>
Re: Type cast removal - proposed exceptions for xml,enum Tom Lane <tgl@sss.pgh.pa.us>
Re: Type cast removal - proposed exceptions for xml,enum Mike Christensen <mike@kitchenpc.com>
On Mon, Dec 6, 2010 at 7:49 PM, Craig Ringer
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.
В списке pgsql-general по дате отправления