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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: WIP pgindent replacement
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_upgrade using appname to lock out other users