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