Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL

> > I have to admit I usually find this very confusing with Informix.
>
> I can't disagree. The way informix decided to do DATETIME stuff is
> definately odd. That said, from a calcualtion standpoint you can pretty
> much ignore the qualifier during calcualtions, its only really important
> in the representation. (I'm actually making assumptions here, and it
> produces considerable work at the representation stages, but that can
> easily be accomodated).

Yes, I don't want to start having explain that mess to people.

>
> >
> > > 2/ Interval type specifiers (ditto)
> > > o informix uses interval specifiers of the form
> > > INTERVAL DAY TO HOUR. (which is just the
> > > day and hour portion of an interval).
> >
> > This I can usually understand, though I think we can do this too clearer
> > than Informix.
> >
> > > 3/ Money type specifiers
> > > o informix has money type specifiers that are akin
> > > to decimal speicifiers
> >
> > We have a MONEY type now, and are looking to invisibly use DECIMAL for
> > this instead.
> >
>
> This would actually be sensible. My comment about money, is that the
> existing type doesn't have a concept of precision; two decimal places of
> money is somewhat meaningless where in the local currency it takes 1000
> washers to buy a packet of crisps. The ability to set the precision of
> the MONEY type is kinda important in this case.

The move to make MONEY use decimal would add precision.

> > > 5/ serial data type
> > > o Serial type must return inserted key value
> >
> > How does Informix return the value?
> >
>
> >From a user standpoint it mystically appears in sqlca just after the
> insert statement is executed. Actually the informix engine recognises
> it's just done a serial insert, and sends it back in addition to the
> standard status packets.

Yes, we have currval() which allows such retrieval _inside_ the
database, as well as in the application.

> I can understand the situation here (one of the main reasons I raised the
> thread in the first place). Above all else the difficulty I have with
> serial at the moment is the impossibility of differentiating a serial with
> an int4 after creation (after all the database treats them identically).
> The catalog tables don't contain any information. The only way you can
> work out you created a serial column is by looking for an appropriately
> named sequence in the database on every int4 column that exists (or am I
> wrong?). This is not exactly something that appeals to me

Yes, the SERIAL gets lost once it is created. This can cause confusion
because doing a \dt on the table shows it as an INT4 with DEFAULT, and
not a serial. This can confuse people. I remember someone saying we
would need to keep the SERIAL understanding around so we would use it
for pg_dump, but I don't remember why we needed to do that.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026