Re: RfD: more powerful "any" types
От | Pavel Stehule |
---|---|
Тема | Re: RfD: more powerful "any" types |
Дата | |
Msg-id | 162867790909111033u7ad61d01v26068641f26fe371@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RfD: more powerful "any" types (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
2009/9/11 Tom Lane <tgl@sss.pgh.pa.us>: > Merlin Moncure <mmoncure@gmail.com> writes: >> If you are going to use printf format codes, which is good and useful >> being something of a standard, I'd call routine printf (not format) >> and actually wrap vsnprintf. The format codes in printf have a very >> specific meaning: converting native C types to arrays of characters. >> I think that a postgresql implementation should do exactly that: >> attempt to convert the passed in datum to the c type in question if >> possible (erroring if no cast exists) and then pass it down. > > I think this is a bit too restrictive. Aside from the issue of loss of > precision for NUMERIC, do we really want users to have to deal with the > fact that "long" doesn't mean the same thing on every platform? I don't > want the same SQL to work on some platforms and fail on others because > a particular datatype has a cast to int4 and not to int8, for instance. > > We should certainly leverage the C library as much as we can for this, > but exposing users to every single idiosyncrasy of C is not quite the > right thing IMHO. > I am thinking so PostgreSQL sprintf function that isn't real sprintf function is really perfect idea. I see messages, sprintf doesn't support format correctly ... And I will have three sprintf functions, perl, c and postgres, ... still are you thinking, so this is good idea? regards Pavel Stehule > regards, tom lane >
В списке pgsql-hackers по дате отправления: