Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL - Mailing list pgsql-hackers

> > 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@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026