Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL |
Дата | |
Msg-id | 200001061812.NAA15830@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL (Rod Chamberlin <rod@querix.com>) |
Ответы |
Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL
(Rod Chamberlin <rod@querix.com>)
|
Список | 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
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Bernard Adrian FrankpittДата:
Сообщение: Re: [HACKERS] Proposed cleanup of index-related planner estimation procedures
Следующее
От: Bruce MomjianДата:
Сообщение: Re: [HACKERS] Enhancing PGSQL to be compatible with Informix SQL