Re: [HACKERS] varchar() vs char16 performance

Поиск
Список
Период
Сортировка
От Andrew Martin
Тема Re: [HACKERS] varchar() vs char16 performance
Дата
Msg-id 199803131018.KAA09788@bsmir06.biochem.ucl.ac.uk
обсуждение исходный текст
Список pgsql-hackers
> > If char2 et al are going completely from 6.4, I think it would be sensible
> > for pg_dump to filter these types and change them to char(2) et al when
> > it writes the CREATE statments.
> >
>
> That is an interesting idea, but what about applications that use them?
> I think we can have the parser change them for one release, then drop
> them completely.
>
Not just an interesting idea, but essential!

There are two separate issues here:
1. Migrating data between PostgreSQL versions
2. Migrating applications between PostgreSQL versions

My suggestion for modifying pg_dump addresses the first of these. Without
this fix, it will become impossible to migrate data without editing the
dump file. The problem of column names mentioned before is not so
serious as one can change the column name in the old version of the
database before dumping (providing you know this is necessary! A list
of depracated column names in the upgrade procedure would be useful,
or better pg_dump would tell you...). With changes of type, there is
no option but to edit the dump file. If that happens to be bigger than
your total VM you are stuffed! (I guess you could mess around with
head and tail to split the file up or write a Perl script to modify
the schemae, but we shouldn't be expecting users to do this...)

An alternative workaround would be for pg_dumpall to have an option
where it makes use of the pg_dump's ability to dump only the data
or only the schema. That way one could edit just the schemae which
will be small and not have to touch the actual data dumps. However,
this really isn't necessary if pg_dump does the filtering.

Issue 2 really isn't a problem. Providing there are adequate warnings
in the upgrade information, developers can quite simply alter the
applications they write which use CREATE statements. These warnings
should *stay in the upgrade information* for evermore... We must
not assume that people who are happy with a release they have of
PostgreSQL will upgrade everytime a new version comes out.



Andrew

----------------------------------------------------------------------------
Dr. Andrew C.R. Martin                             University College London
EMAIL: (Work) martin@biochem.ucl.ac.uk    (Home) andrew@stagleys.demon.co.uk
URL:   http://www.biochem.ucl.ac.uk/~martin
Tel:   (Work) +44(0)171 419 3890                    (Home) +44(0)1372 275775

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Zeugswetter Andreas
Дата:
Сообщение: Re: [HACKERS] PL/pgSQL - for discussion (RETURN)
Следующее
От: Michael Meskes
Дата:
Сообщение: Keyword