X-Original-To: pgsql-bugs-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id 357C6D1B199;
	Sun,  4 Jul 2004 20:19:40 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 69378-02; Sun,  4 Jul 2004 23:19:38 +0000 (GMT)
Received: from mail.svhost.com.ar (mail.svhost.com.ar [200.80.239.22])
	by svr1.postgresql.org (Postfix) with ESMTP id 9AAD2D1B172;
	Sun,  4 Jul 2004 20:19:33 -0300 (ADT)
Received: from sistemat.com.ar (devel.sistemat.com.ar [192.168.1.40])
	by mail.svhost.com.ar (Postfix) with ESMTP
	id 08C0423A0F; Sun,  4 Jul 2004 20:18:26 -0300 (ART)
Message-ID: <40E89282.9060306@sistemat.com.ar>
Date: Sun, 04 Jul 2004 20:28:02 -0300
From: "Dario V. Fassi" <software@sistemat.com.ar>
Organization: SISTEMATICA ingenieria de software srl
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: es, es-ar, en-us, en
MIME-Version: 1.0
To: Stephan Szabo <sszabo@megazone.bigpanda.com>
Cc: Kris Jurka <books@ejurka.com>, pgsql-jdbc@postgresql.org,
	pgsql-bugs@postgresql.org, pgsql-sql@postgresql.org
Subject: Re: [JDBC] Error in DatabaseMetaData.getColumns() with Views
References: <40E6088E.6030703@yahoo.com.ar>
	<Pine.BSO.4.56.0407030343090.19721@leary.csoft.net>
	<40E6E7AF.5020306@sistemat.com.ar> <40E6FD7F.50801@sistemat.com.ar>
	<Pine.BSO.4.56.0407041330180.26773@leary.csoft.net>
	<20040704153840.Y52747@megazone.bigpanda.com>
In-Reply-To: <20040704153840.Y52747@megazone.bigpanda.com>
Content-Type: multipart/alternative;
	boundary="------------030901000008080708020206"
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.5 tagged_above=0.0 required=5.0 tests=HTML_MESSAGE,
	HTML_TITLE_EMPTY
X-Spam-Level: 
X-Archive-Number: 200407/60
X-Sequence-Number: 8642

This is a multi-part message in MIME format.
--------------030901000008080708020206
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Stephan Szabo wrote:

>On Sun, 4 Jul 2004, Kris Jurka wrote:
>
>  
>
>>On Sat, 3 Jul 2004, Dario V. Fassi wrote:
>>
>>    
>>
>>>In the sample adjunct, you can see that error arise at the time when the
>>>view's sql text is parsed and saved in database catalog.
>>>Then generic NUMERIC type is forced for every calculated column without
>>>regard or precision.
>>>And at execute time the f2 column has varying type decimals (in row 2
>>>you can see 4 decimals and in other rows has 3 decimals), this is not a
>>>behavior , this is an ERROR.
>>>      
>>>
>
>[Jumping in, because this was the first message of the thread I've seen]
>
>Technically, the correct behavior by spec would be an
>implementation-defined precision and a particular scale based on the
>argument scales. So, having numeric(6,2)+numeric(6,2) return
>numeric(65535, 2) is fine. Returning numeric(65535, 65531) isn't
>technically, but I don't think this is an issue in the jdbc metadata
>getting as much as an issue in the database proper.
>

I agree with all your spech but a  numeric data type like numeric(65535, 
2) isn't a very serious return value.
A value like this could be usefull to eliminate the need of presicion 
specification in numeric data type too.
Of course it's a dabase proper issue , but impact in my needs in jdbc 
usability.
No matter what's technically or not, a behavior at this point like those 
of db2/oracle would be very nice ;-)


--------------030901000008080708020206
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
<br>
Stephan Szabo wrote:<br>
<blockquote type="cite"
 cite="mid20040704153840.Y52747@megazone.bigpanda.com">
  <pre wrap="">On Sun, 4 Jul 2004, Kris Jurka wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">On Sat, 3 Jul 2004, Dario V. Fassi wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">In the sample adjunct, you can see that error arise at the time when the
view's sql text is parsed and saved in database catalog.
Then generic NUMERIC type is forced for every calculated column without
regard or precision.
And at execute time the f2 column has varying type decimals (in row 2
you can see 4 decimals and in other rows has 3 decimals), this is not a
behavior , this is an ERROR.
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->
[Jumping in, because this was the first message of the thread I've seen]

Technically, the correct behavior by spec would be an
implementation-defined precision and a particular scale based on the
argument scales. So, having numeric(6,2)+numeric(6,2) return
numeric(65535, 2) is fine. Returning numeric(65535, 65531) isn't
technically, but I don't think this is an issue in the jdbc metadata
getting as much as an issue in the database proper.</pre>
</blockquote>
<br>
I agree with all your spech but a&nbsp; numeric data type like
numeric(65535, 2) isn't a very serious return value.<br>
A value like this could be usefull to eliminate the need of presicion
specification in numeric data type too.<br>
Of course it's a dabase proper issue , but impact in my needs in jdbc
usability.<br>
No matter what's technically or not, a behavior at this point like
those of db2/oracle would be very nice ;-)<br>
<br>
</body>
</html>

--------------030901000008080708020206--