Re: BUG #1712: JDBC column precision for bigint is 0
От | Oliver Jowett |
---|---|
Тема | Re: BUG #1712: JDBC column precision for bigint is 0 |
Дата | |
Msg-id | 42AE012D.9000600@opencloud.com обсуждение исходный текст |
Ответ на | Re: BUG #1712: JDBC column precision for bigint is 0 (Gilles Dubochet <dubochet@urbanet.ch>) |
Список | pgsql-bugs |
Gilles Dubochet wrote: >>> Whith the JDBC driver at least up to version 8.1dev-400, the result >>> of the >>> getPrecision method of ResultSetMetaData on a bigint column is 0 >>> instead of >>> the expected 19. >>> >> >> This has been reported before but I haven't got to fixing it yet. This >> is partly because I haven't seen a good explanation of exactly what we >> should be returning here -- what spec says we should return 19? > If you count the number of digits in these numbers, you'll notice that > for the signed number, 19 decimal digits at most are required to > represent it (if the sign comes for free, which seems assumed for other > data types such as INT or SMALLINT). [...] > This is why I believe 19 is the value the getPrecision method should > return. I don't think there is some kind of standard reference that > defines it, but it seems pretty clear what it should be really. The problem I have is how we decide that "precision" means "number of digits, ignoring sign". Actually, I just dug through the JDBC javadoc, and noticed that ResultSetMetaData.getPrecision() does talk about the number of decimal digits; but in all the other places it's used (such as DatabaseMetaData) it's not described. For numeric types using number of decimal digits seems reasonable since it's consistent with the NUMERIC type's precision/scale information. Previous reports of this also wanted to provide precision for dates and times according to the number of digits in them, which seems much more dubious. I guess it's another case of the JDBC specification being woefully underspecified :( -O
В списке pgsql-bugs по дате отправления: