Re: bug report: slow getColumnTypeName - Mailing list pgsql-jdbc

The way postgresql implements serial (int from a sequence, with a
alias of serial) is really nice because it gives sequence and serial
interface to a column, but looks like a hack.

We create a column with type serial, when we ask postgresql to
describe it, it says it's an int.

The JDBC driver (or any other driver) should not fix/circumvent
postgresql definition, but only to map the database types to JDBC
types.

Is the database defines the type as an int, then it's an int alright.
The JDBC driver is just a bridge, a connector, it should not define
new data types.

In the current implementation, the result of getColumnType and
getColumnTypeName is also incoherent, int constant vs "serial" name.

So, work should be done upstream to fix this, at the database layer,
they should make up their mind, is it an int or a serial, serial is a
real type, or just an alias?

For now, it seams to me, the more correct thing is to deliver what the
database delivers ... int


Luis Flores

On Wed, Oct 17, 2012 at 10:27 AM, Dave Cramer <pg@fastcrypt.com> wrote:
> On Wed, Oct 17, 2012 at 12:56 AM, Craig Ringer <ringerc@ringerc.id.au> wrote:
>> On 10/17/2012 07:28 AM, Dave Cramer wrote:
>>>
>>> So what is the consensus on this.
>>>
>>> I would lean towards removing serial types here
>>
>>
>> I certainly want to, as I think the status quo is not only inefficient and
>> incorrect but it fails to even function as designed (incorrectly calling
>> 'integer' columns generated by a sequence 'serial' no matter what the
>> sequence is) and cannot easily be fixed.
>>
>> The questions that must still be answered are:
>>
>> - How do we tell developers about the change?
>>
>> - Is a compatibility flag required?
>>
>> - What might it break? Do we need to test popular ORM systems or let
>>   their developers know?
>>
>> - What does the metadata spec actually require us to supply?
>>
>>
>> The 9.2 driver has been pushed and it's a backwards-incompatible change, so
>> it's probably a change that's only suitable for 9.3/master. I'm inclined to
>> just make the change in master, push a beta driver to the website, and see
>> it reports come in. I can test Hibernate and EclipseLink out, but I'm pretty
>> sure they won't care.
>>
>>
>> BTW, I'm quite surprised that PostgreSQL doesn't expose information about
>> column value generation in INFORMATION_SCHEMA.COLUMNS at the moment; the
>> "is_identity" column is always "NO" and "is_generated" is always "NEVER".
>> `pg_attribute` doesn't seem to convey it either. Shouldn't we be able to ask
>> PostgreSQL for this information?
>>
>> I'll have a look and see how the driver currently reports whether fields are
>> generated, are identity fields, etc.
>>
>> Looking at the number of issue reports that focus on metadata, I suspect
>> that's a real weak point of the current driver and really needs a review.
>> Yay. Something for all that abundant spare time.
>
> So I spent some more time on this. This change was made in 2004. Why
> is it only a problem now ?
>
> Yes, metadata is the big issue. Postgres just doesn't expose it like
> others do. If it were easy the metadata would have been done.
>
> As far as int + default nextval goes, that sort of is the definition
> of a serial.
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
>
>>
>>
>> --
>> Craig Ringer
>>
>>
>> --
>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc