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

On Wed, Oct 17, 2012 at 6:43 AM, Luis Flores <luiscamposflores@gmail.com> wrote:
> 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,

We're sort of all in agreement with above, however removing the
existing code may break existing code.


Dave Cramer

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



> 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
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc