Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef
От | Oliver Jowett |
---|---|
Тема | Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef |
Дата | |
Msg-id | 49B5E761.4060507@opencloud.com обсуждение исходный текст |
Ответ на | Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef
|
Список | 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 по дате отправления: