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