Re: [JDBC] JPA + enum == Exception

Поиск
Список
Период
Сортировка
От Vitalii Tymchyshyn
Тема Re: [JDBC] JPA + enum == Exception
Дата
Msg-id CABWW-d16=dv++=MbKid6N4iTYGaCxoSr_pWdhRCm3XyVFj13FQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [JDBC] JPA + enum == Exception  (Kevin Grittner <kgrittn@ymail.com>)
Список pgsql-hackers

This is not entirely unrelated to the discussions about allowing
broader use of automatic casting server-side.  It seems to me that
on one side of the argument is the idea that strict typing reduces
bugs and doesn't lead to problems with ambiguity, especially as
things change; and on the other side the argument is that where no
ambiguity exists we would make life easier for developers of
applications or access tools if we relexed things beyond what the
related specifications require, and that not doing so discourages
adoption.  I think that all the same arguments apply here with
equal force, on both sides of the issue.

The problem with this debate has always been that both sides are
completely right.  Those are always the toughest to resolve.  It
comes down to which evils we tolerate to garner which benefits.  It
seems that in such cases inertia tends to win.  I'm not so sure
that it should.  An ideal solution would find some way to address
the concerns of both sides, but so far that has eluded us when it
comes to the type system.


As for me, "right way" would be to allow exactly same casting as when using literals. Because now there are a lot of complaints like "It's driver problem because it works in psql". 

Best regards, Vitalii Tymchyshyn

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Re: proposal: a width specification for s specifier (format function), fix behave when positional and ordered placeholders are used
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: PATCH: Split stats file per database WAS: autovacuum stress-testing our system