Обсуждение: [HACKERS] A defect report and a question about money.

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);

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.)

- --
Jonathan Guthrie (jguthrie@brokersys.com)
Information Broker Systems   +281-895-8101   http://www.brokersys.com/
12703 Veterans Memorial #106, Houston, TX  77014, USA

We sell Internet access and commercial Web space.  We also are general
network consultants in the greater Houston area.

------------------------------

> 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.

D'Arcy J.M. Cain implemented the money type for v6.1 from code found in
the book "Software Solutions in C". I helped to integrate it into
Postgres.

We are hoping to get enough platforms with 64-bit integers to allow us
to move to a 64-bit money type.

What else do you want to do with the money type? Start talkin' (perhaps
off-list with D'Arcy and I unless we aren't getting you where you want
to go with it :)

            - Tom

------------------------------

Thus spake Jonathan Guthrie
> 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.)

I was the one who added the money type.  What kind of changes did you want
to see?

- --
D'Arcy J.M. Cain                           |  Democracy is three wolves
darcy@{druid.net|vex.net}                  |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.
                --  http://www.druid.net/darcy  --

------------------------------

End of hackers-digest V1 #389
*****************************

>
>
> 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

------------------------------