Re: bug report: slow getColumnTypeName

On 10/11/2012 10:07 PM, Luis Flores wrote:
> You are talking about a different matter.
> 1. 802 and prior drivers named serials as int4 (and big serials int8)
> 2. 900 and newer drivers named serials as serials (and you got a
> performance hit from that)
>
> We are now attempting to solve the problem #2, maintain the correct
> column name (serial and big serial), and if possible improve
> performance.

I strongly disagree with this approach. "serial" and "bigserial" are
*not* the correct column names. "serial" and "bigserial" are effectively
macros and cease to exist in any meaningful way once expanded.

Even if showing "serial" or "bigserial" were free, I'd still want to
show the underlying types "integer" and "biginteger".

Showing "serial" is not consistent with psql:

regress=# CREATE TABLE blah ( id serial primary key);
NOTICE: CREATE TABLE will create implicit sequence "blah_id_seq" for
serial column "blah.id"
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"blah_pkey" for table "blah"
CREATE TABLE
regress=# \d blah
Table "public.blah"
Column | Type | Modifiers
--------+---------+---------------------------------------------------
id | integer | not null default nextval('blah_id_seq'::regclass)
Indexes:
"blah_pkey" PRIMARY KEY, btree (id)

... nor with INFORMATION_SCHEMA:

select * from information_schema.columns WHERE table_schema = 'public'
AND table_name = 'blah';

-[ RECORD 1 ]------------+---------------------------------
table_catalog | regress
table_schema | public
table_name | blah
column_name | id
ordinal_position | 1
column_default | nextval('blah_id_seq'::regclass)
is_nullable | NO
data_type | integer
numeric_precision | 32
numeric_precision_radix | 2
numeric_scale | 0
...
udt_catalog | regress
udt_schema | pg_catalog
udt_name | int4
...
dtd_identifier | 1
is_self_referencing | NO
is_identity | NO
...
is_generated | NEVER
...
is_updatable | YES

> If you use a column with a default value from a sequence, the column
> type name doesn't change. If the column is int AND is generated from a
> sequence called <TABLE>_<COLUMN>_seq, then in postgresql (you can
> check in pgadmin)

PgAdmin is doing something funky; that doesn't mean PgJDBC should.

--
Craig Ringer