Re: [HACKERS] A defect report and a question about money.
| От | Bruce Momjian |
|---|---|
| Тема | Re: [HACKERS] A defect report and a question about money. |
| Дата | |
| Msg-id | 33b19c18dacb0ca947d21ec5be0ea851 обсуждение исходный текст |
| Ответ на | [HACKERS] A defect report and a question about money. (Jonathan Guthrie <jguthrie@brokersys.com>) |
| Список | pgsql-hackers |
> > > Recently (last Saturday, as it happens) I upgraded from PostgreSQL v6.0 to > v6.1. I believe I followed the correct procedure for saving the old > databases, and then restoring them in the new format. However, the > process didn't work quite right. > > In particular, I had some indexes that were built around a function that > looks like this: > > CREATE FUNCTION strcatc2c16 (char2,char16 ) RETURNS text AS > '/home/postgres/src/strcat/strcat.so' LANGUAGE 'C'; > > The index definition I created looked like this: > > CREATE UNIQUE INDEX specialization_index ON specialization USING btree > (strcatc2c16(code, stateBarNum) char_ops); > > But in the "db.out" file, it looked like this: > > CREATE UNIQUE INDEX specialization_index on specialization using btree > (strcatc2c16(code) char_ops); > I just tested this under 6.1 of pg_dumpall, and got: CREATE UNIQUE INDEX specialization_index on specialization using btree (strcatc2c16 (code, statebarnum) char_ops ); So it looks like it was broken in 6.0, but fixed in 6.1, which doesn't help your migration from 6.0, but shows it will work when you dump 6.1. > No real harm done. I don't know if composite unique indices didn't work > in v6.0 or if I just didn't know about them so I didn't use them, but I > reworked my database code to use them instead of the string concatenation > function. > > However, it seems that there is a defect in pg_dumpall because it gets the > number of parameters wrong in that case. > > Also, one of the features I was interested in in v6.1 (and, in addition to > the desire to upgrade before the Houston NW Bar Association WWW page is > operational, the real reason I upgraded early,) is the money data type. I > had done extensive work on my own currency data type in v6.0 and I wanted > to quickly switch to a system with a built-in type of that sort. However, > there are some features I desire from currenty types and I'd like to see > if I can't get them included in Postgres. Is there ongoing work on the > "money" data type? If so, how can I be a part of it. (Ideally, I'd like > to sort of take it over. Kind of meld it in my own image or some such.) There is a Money type in 6.1, but it does not have a user-defined length, yet. - -- Bruce Momjian maillist@candle.pha.pa.us ------------------------------
В списке pgsql-hackers по дате отправления: