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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: "Dickson S(dot) Guedes" <listas(at)guedesoft(dot)net>, pgsql-jdbc <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef
Date: 2009-03-10 04:37:02
Message-ID: 21668.1236659822@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Oliver Jowett <oliver(at)opencloud(dot)com> 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

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Guillaume Cottenceau 2009-03-10 08:05:52 Re: [PERFORM] Query much slower when run from postgres function
Previous Message Oliver Jowett 2009-03-10 04:06:57 Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef