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 03:54:08 |
Message-ID: | 21151.1236657248@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:
>> What's the default value being used for anyway?
> I'm guessing that particular query is from
> DatabaseMetaData.getColumns(), which returns amongst other things:
> 13. COLUMN_DEF String => default value (may be null)
> (yes, that's the sum total of the JDBC documentation about that piece of
> metadata)
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.
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2009-03-10 04:06:57 | Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef |
Previous Message | Oliver Jowett | 2009-03-10 03:44:08 | Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef |