Re: BUG #3894: JDBC DatabaseMetaData.getTables is inconsistently case-sensitive with schema name
От | Adam Hardy |
---|---|
Тема | Re: BUG #3894: JDBC DatabaseMetaData.getTables is inconsistently case-sensitive with schema name |
Дата | |
Msg-id | 47B2ECC4.4010806@cyberspaceroad.com обсуждение исходный текст |
Ответ на | Re: BUG #3894: JDBC DatabaseMetaData.getTables is inconsistently case-sensitive with schema name (Kris Jurka <books@ejurka.com>) |
Список | pgsql-bugs |
Kris Jurka on 12/02/08 16:40, wrote: > On Tue, 12 Feb 2008, Adam Hardy wrote: >> Because this rules out certain important features of the JPA >> framework such as native SQL queries, you may want to prioritize this >> issue. I will have to use Oracle or mySQL until PostgreSQL can >> rectify things. > > I wouldn't expect postgresql to change anytime soon. Could you > explain in more detail what you can't use and why the JPA side > couldn't be fixed to support postgresql? > > You could also consider always quoting all identifiers in both > database creation scripts and queries. This guarantees that the > database won't mess with the case of the object although it can be a > pain to type if you writing a lot of queries by hand. Well, JPA is just a standard, so a 'JPA fix' would require each JPA provider (Toplink, JDO, OpenJPA, Hibernate etc) to rectify their postgresql-specific dialect / SQL syntax builder. This issue arises using PostgreSQL with a schema name when running native SQL queries. That means I write pure SQL in my JPA mapping files. It's a common practice. Using a schema name is also a common practice. However I will, at some stage in the future, code a test batch, which tests basic CRUD functionality and OR mapping across different combinations of JPA providers and DB vendors. So I will keep the bug reference handy and let you know how many JPA providers suffer this issue once I run the test. Best regards Adam
В списке pgsql-bugs по дате отправления: