Re: Identifying no-op length coercions
От | Robert Haas |
---|---|
Тема | Re: Identifying no-op length coercions |
Дата | |
Msg-id | BANLkTimY8tmxiY2eEWR36ApciyyhwcV+rw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Identifying no-op length coercions (Alexey Klyukin <alexk@commandprompt.com>) |
Список | pgsql-hackers |
On Tue, Jun 21, 2011 at 5:50 PM, Alexey Klyukin <alexk@commandprompt.com> wrote: > On Jun 21, 2011, at 9:58 PM, Noah Misch wrote: >> A pg_regress test needs stable output, so we would do it roughly like this: >> >> CREATE TEMP TABLE relstorage AS SELECT 0::regclass AS oldnode; >> ... >> UPDATE relstorage SET oldnode = >> (SELECT relfilenode FROM pg_class WHERE oid = 'test'::regclass); >> ALTER TABLE test ALTER name TYPE varchar(65535); >> SELECT oldnode <> relfilenode AS rewritten >> FROM pg_class, relstorage WHERE oid = 'test'::regclass; >> >> I originally rejected that as too ugly to read. Perhaps not. > > Yes, your example is more appropriate. I think you can make it more > straightforward by getting rid of the temp table: > > CREATE TABLE test(oldnode oid, name varchar(5)); > > INSERT INTO test(oldnode) SELECT relfilenode FROM pg_class WHERE > oid='test'::regclass; > > ALTER TABLE test ALTER name TYPE varchar(10); > > SELECT oldnode <> relfilenode AS rewritten FROM pg_class, test WHERE > oid='test'::regclass; Without wishing to foreclose the possibility of adding a suitable regression test, I've committed the main patch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: