Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef

From: Tom Lane
Subject: Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef
Date: ,
Msg-id: 21668.1236659822@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef  (Oliver Jowett)
Responses: Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef  (Kris Jurka)
List: pgsql-jdbc


Oliver Jowett <> writes:
> Tom Lane wrote:
>> pg_catalog.pg_get_expr(adbin, adrelid)

> 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?

According to the pg_dump sources, that's good back to 7.3 ... do you
care about earlier?

>> 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)

Fair enough.  I was just trying to remember whether the planner was
smart enough to consider LIKE 'constant-pattern' to be equivalent to
= 'constant-pattern' even when the locale prevents doing anything
smarter for non-constant patterns.  But that'd be my problem to fix not
yours ...

            regards, tom lane


pgsql-jdbc by date:

From: Guillaume Cottenceau
Date:
Subject: Re: [PERFORM] Query much slower when run from postgres function
From: "Dickson S. Guedes"
Date:
Subject: Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef