Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef - Mailing list pgsql-jdbc

From Oliver Jowett
Subject Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef
Date
Msg-id 49B5E761.4060507@opencloud.com
Whole thread Raw
In response to Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-jdbc
Tom Lane wrote:

> Hmm.  The correct, pg_dump-tested way to get the default expression is
>     pg_catalog.pg_get_expr(adbin, adrelid)
> but that's fairly expensive.  I'm having a hard time recommending
> that you put it into DatabaseMetaData.getColumns, when probably 99.99%
> of applications won't even look at the value let alone care if it is
> stale.  OTOH the joins involved are not-cheap already, so maybe this
> worry is just premature micro-optimization.

I don't think DBMD.getColumns() is expected to be called all that much,
certainly not in performance-critical paths, so perhaps the more complex
expression is the way to go. How far back, version-wise, will that
expression work?

> BTW, is there a reason for the query to be using LIKE 'name' instead of
> = 'name'?  And if so, is whatever generates it smart about underscores
> and % and \ in the name?

The API lets the application specify a pattern to search on, using the
same syntax that LIKE expects, so the driver just passes it straight
through into the query (modulo normal string escaping)

-O

pgsql-jdbc by date:

Previous
From: Tom Lane
Date:
Subject: Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef
Next
From: Tom Lane
Date:
Subject: Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef