Re: bug report: slow getColumnTypeName

So what is the consensus on this.

I would lean towards removing serial types here

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On Fri, Oct 12, 2012 at 6:06 AM, Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> wrote:
> On 10/12/2012 04:39 PM, Luis Flores wrote:
>>
>> I agree, my only doubt is about the reasons behind the change, the driver
>> was reporting int4, int8, and then was changed, why?
>
>
> Yep, that I'd like to know. The change appears to be:
>
> commit ddf8296bead68552a8e5de0f5bb20875273bb02d
> Author: Kris Jurka <books(at)ejurka(dot)com>
> Date: Thu Sep 30 07:58:11 2004 +0000
>
> Return serial datatypes in both getTypeInfo and getColumns methods.
>
> Jaroslaw J. Pysnzy
>
> Also add a test case for this and fix my previous regression test
> breakage on 7.2 servers. With serial columns before dependency
> information dropping a table did not drop the sequences that went
> with it. Explicitly drop them.
>
> Kris Jurka
>
>
>
> see git diff
> ddf8296bead68552a8e5de0f5bb20875273bb02d..8c9d68ee7763851732de0bd0d14b2b51cdfe0622
>
>
> That code is all kinds of wrong. Check this out:
>
> if ( defval != null ) {
> if ( pgType.equals("int4") ) {
> if (defval.indexOf("nextval(") != -1)
> tuple[5] = connection.encodeString("serial");
> }
> else if ( pgType.equals("int8") ) {
> if (defval.indexOf("nextval(") != -1)
> tuple[5] = connection.encodeString("bigserial");
> }
> }
>
>
>
> *any* int4 or int8 with a DEFAULT nextval(... is reported as "serial" or
> "bigserial" whether or not it is. See AbstractJdbc2DatabaseMetaData.java
> line 2480.
>
>
> --
> Craig Ringer
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc