Обсуждение: Compilation problems and extension on Windows
Hi list,
I asked both these questions on the cygwin list, but as I've started to
look into the native port as well, and as I didn't get any answer there,
I would appreciate any answer here as well.
I'm trying to compile an external library for use as a postgres
extension. The project is available on pgfoundry (search for mssqlext).
On Unix everything works great. On Windows, I'm trying for both a cygwin
and a native version of the extension. I'm having several problems:
1. I cannot link the library without postgres.exe (that has several of
the functions I need). However, I do not have access to the link library
for it.
2. I have downloaded both the sources from the web and the sources
available in the cygwin installer. They are not the same. Neither
compiles on cygwin, however.
3. I have not located any instructions for compiling the native sources
(8.0 beta 1). The makefiles available through the sources only compile
libpq and psql and friends, not the actual database. I have not tried
MSYS yet, but do I just run the configure script as usual?
Any help with any of these problems would be greatly appretiated.
Shachar
--
Shachar Shemesh
Lingnu Open Systems Consulting
http://www.lingnu.com/
I found a little bug in monetary function of postgresql function cash_in in file cash.c the problem is that when I run set lc_monetary to "fa_IR.UTF8" and try to insert a value to a field with type of money, I got the following error: "invalid input syntax for type money: "1000" at the same time when I run "set lc_monetary to "en_US.UTF8", everythings worked well. I studied the source code and I found that cash.c has a little problem to handling money type. I found that this bug exists for all of countries that have not precision for their money. I decided to write a patch for this bug, but before I start my work, i want to know if anyone has any idea about this bug or not? a dirty method to fix this bug is to replace following line if (isdigit((unsigned char) *s) && dec < fpoint ) with if (isdigit((unsigned char) *s) && ((dec < fpoint) || fpoint == 0)) M, Taghizade Regards __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Dear All,
we are envolving in a national project and we want to
add our locale support in postgreSQL. we found that
the postgreSQL does not support locale very well. we
want to start our work by translation some part of
postgreSQL documents. then fix some little bug about
our locale in postgreSQL and our main target is adding
locale support per column.
1. we want to translate some postgreSql documents
(FAQ, tutorial for start). I want to know who is
responsible for this part in postgreSQL (we are from
IRAN)
2. there is a little bug about our monetary in
postgreSQL (locale), if I want to fix it who is
responsible to contact with him.
3. we are planning to add locale per column for
postgreSQL, but I found that you had said its
impossible. am I right? do you have any paper about
it?
4. If I want to add collate order for postgreSQL what
should I do? is there any guideline for adding this
feature in postgreSQL
Please dont us alone in this project, we need your
help and guidlines.
I am thankful in advance.
Regards
=====
With Regards,
--taghi
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
Mahmoud Taghizadeh wrote: > 1. we want to translate some postgreSql documents > (FAQ, tutorial for start). I want to know who is > responsible for this part in postgreSQL (we are from > IRAN) You are. :) > 2. there is a little bug about our monetary in > postgreSQL (locale), if I want to fix it who is > responsible to contact with him. This list. > 3. we are planning to add locale per column for > postgreSQL, but I found that you had said its > impossible. am I right? do you have any paper about > it? It's possible, but difficult. > 4. If I want to add collate order for postgreSQL what > should I do? is there any guideline for adding this > feature in postgreSQL Collation order support needs to be provided by the operating system locales. I think Farsi should be supported. If in doubt, read the documentation. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Sun, 22 Aug 2004, Mahmoud Taghizadeh wrote: > 3. we are planning to add locale per column for > postgreSQL, but I found that you had said its > impossible. am I right? do you have any paper about > it? > > 4. If I want to add collate order for postgreSQL what > should I do? is there any guideline for adding this > feature in postgreSQL Impossible is way to strong word. It's just a lot of work. Encoding and collation order should be per column (is there any more local information needed then collation order?). In fact, each string handled inside pg need such information stored. It's similar to a type of an object, and can probably be handled in a similar way. What I suggest is that you first check out the sql specification (already sql92 includes this) and whatever solution made should support what's in the standard (or at least be as close as possible). We don't just want to code up something that works somewhat and that later makes it hard to do the right thing demanded by the standard. I'm not saying that one have to do everything that's in the standard, just that what we do should not break the standard in arbitrary ways. -- /Dennis Björklund
Mahmoud Taghizadeh <m_taghi@yahoo.com> writes:
> a dirty method to fix this bug is to replace following
> line
> if (isdigit((unsigned char) *s) && dec < fpoint )
> with
> if (isdigit((unsigned char) *s) && ((dec < fpoint) ||
> fpoint == 0))
This patch is wrong. Something involving "!seen_dot || dec < fpoint"
would probably be better. On the other hand, I can see half a dozen
other brokennesses in that routine on idly glancing over it :-(
Are you aware that the monetary type is deprecated and is going to be
dropped entirely pretty soon? I would not recommend that you spend
any time on it, unless you want to commit to doing a wholesale rewrite.
Store your financial data in NUMERIC columns instead --- no overflow
worries, for one thing.
regards, tom lane
Tom Lane wrote: > Mahmoud Taghizadeh <m_taghi@yahoo.com> writes: > >>a dirty method to fix this bug is to replace following > Are you aware that the monetary type is deprecated and is going to be > dropped entirely pretty soon? What's taking so long? ;-) Mike Mascari
Mike Mascari <mascarm@mascari.com> writes:
> Tom Lane wrote:
>> Are you aware that the monetary type is deprecated and is going to be
>> dropped entirely pretty soon?
> What's taking so long? ;-)
We keep hoping someone will step up to the plate and rewrite it, instead.
Per previous discussion, the type really ought to be a thin layer over
"numeric", with most likely no operations of its own except I/O conversion.
regards, tom lane
Tom Lane wrote: > We keep hoping someone will step up to the plate and rewrite it, > instead. Per previous discussion, the type really ought to be a thin > layer over "numeric", with most likely no operations of its own > except I/O conversion. And what would it do with it? Add a currency symbol? Which one? Which form? Where? Format the numbers some way? Sounds like a big mess. Drop it and use to_char. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Sun, 2004-08-22 at 20:40, Tom Lane wrote: > Mike Mascari <mascarm@mascari.com> writes: > > Tom Lane wrote: > >> Are you aware that the monetary type is deprecated and is going to be > >> dropped entirely pretty soon? > > > What's taking so long? ;-) > > We keep hoping someone will step up to the plate and rewrite it, instead. > Per previous discussion, the type really ought to be a thin layer over > "numeric", with most likely no operations of its own except I/O conversion. What are the parameters? Is it an SQL type? It seems to me a monetary type is a complex type consisting of currency code and amount -- but you couldn't sum mixed currencies. Or else it is limited to the currency of the locale, which doesn't seem particularly useful. I think that it should be removed altogether. -- Oliver Elphick olly@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA ======================================== "For yourselves know perfectly that the day of the Lord so cometh as a thiefin the night. For when they shall say, Peace and safety; then sudden destruction cometh upon them, as travailupon a woman with child; and they shall not escape." I Thessalonians 5:2,3
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> We keep hoping someone will step up to the plate and rewrite it,
>> instead. Per previous discussion, the type really ought to be a thin
>> layer over "numeric", with most likely no operations of its own
>> except I/O conversion.
> And what would it do with it? Add a currency symbol? Which one? Which
> form? Where? Format the numbers some way?
The idea behind the money type is to format per the lc_monetary locale
setting, which seems perfectly reasonable to me. Further down the road
we might want per-column locale control, but when we haven't solved that
for text columns it's hardly fair to demand it of type money.
The big beef against the existing money type, IMHO, is the decision to
make the internal representation int32, which makes it hopelessly
overflow-prone. Fix that and I'd stop telling people not to use it.
regards, tom lane
Oliver Elphick <olly@lfix.co.uk> writes:
> It seems to me a monetary type is a complex type consisting of currency
> code and amount -- but you couldn't sum mixed currencies. Or else it is
> limited to the currency of the locale, which doesn't seem particularly
> useful.
In a former lifetime I worked with databases involving amounts of
different currencies, and I didn't find type money useful for that
either. But I think that's a specialized requirement and we'd be
unlikely to consider putting a type that *is* useful for that into
the standard distribution.
I think the money type has very simple, limited goals: give me a numeric
column that has I/O format determined by the current LC_MONETARY setting.
Sure, that doesn't solve every money-related problem, but it would have
usefulness enough to justify the limited amount of implementation effort
involved. The issues with the current implementation aren't really
related to that, they are related to a poor choice of underlying
representation.
> I think that it should be removed altogether.
If no one steps up and fixes it, eventually it will be.
regards, tom lane
Tom Lane wrote: > The idea behind the money type is to format per the lc_monetary > locale setting, which seems perfectly reasonable to me. To me, this seems completely wrong-headed. Data types should be defined by what operations you can do on them, not by what output format they have. With that in mind, a money type that is separate from numeric types could be reasonable, because not all mathematical operations are reasonable on monetary amounts. But most well-designed client interfaces nowadays reparse the text representations of data to present the datum in terms of the client's own data type system, so a money type with a varying and unpredictable output format cannot be reasonably supported and will only create headaches. And even those client interfaces that don't fall into that category will have trouble, because for example you could have trouble sorting the values numerically. So again, if you're looking for a certain display form, use the functions that were made for that purpose. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Sun, 22 Aug 2004 13:29:14 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Are you aware that the monetary type is deprecated and is going to be > dropped entirely pretty soon? I would not recommend that you spend > any time on it, unless you want to commit to doing a wholesale > rewrite. Store your financial data in NUMERIC columns instead --- no > overflow worries, for one thing. And if you have a table with 30,000,000+ records and need to sum a subset of them 100 times per second expect some stress. FWIW I have been working on a contrib module that stores the amount in a 64 bit integer. Perhaps I should submit it as a patch to the existing money type instead. I have fixed up a few other issues while I was at it. -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
On P, 2004-08-22 at 23:07, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > Tom Lane wrote: > >> We keep hoping someone will step up to the plate and rewrite it, > >> instead. Per previous discussion, the type really ought to be a thin > >> layer over "numeric", with most likely no operations of its own > >> except I/O conversion. > > > And what would it do with it? Add a currency symbol? Which one? Which > > form? Where? Format the numbers some way? > > The idea behind the money type is to format per the lc_monetary locale > setting, which seems perfectly reasonable to me. so if you put in $1.00 using en_US.UTF8 then another user using en_CA would get 1.00CAD and I would get 1.00 EEK ? It does make /some/ sense - I would be all for that if this is the sum I mus pay, but object strongly if the sum must be paid *to* me ;) -------------- Hannu
Tom Lane <tgl@sss.pgh.pa.us> writes: > Oliver Elphick <olly@lfix.co.uk> writes: > > It seems to me a monetary type is a complex type consisting of currency > > code and amount -- but you couldn't sum mixed currencies. Or else it is > > limited to the currency of the locale, which doesn't seem particularly > > useful. > > In a former lifetime I worked with databases involving amounts of > different currencies, and I didn't find type money useful for that > either. But I think that's a specialized requirement and we'd be > unlikely to consider putting a type that *is* useful for that into > the standard distribution. Actually I think dimensioned values, or quantities with units attached, would be a very useful datatype for lots of purposes. Both accounting and scientific purposes often need to store things in heterogenous units but then be sure not to perform any inappropriate operations on them. Even if it just asserted that the units matched and permitted the operation it would be useful, without trying to do any fancy dimensional calculus to come up with things like m^2 or m/s etc. fwiw, I agree with the other poster that data types ought to be defined by the operations performed on them, not the display format. In particular I would expect the application to be able to multiply or add to a value pulled from a database even if it's a monetary value, and that wouldn't work if the database insisted on attaching units. It should be the job of strfmon or equivalent to format the value for display. Perhaps what people are really looking for is some kind of column attribute to define the "default" display format to be used. So that applications don't have to hard code parameters to to_char(). There are solutions at the application layer for that, but I could see it being useful to be able to call to_char(column) and have the column know which parameters by default whether it's a date column, numeric column, or cidr datatype. -- greg
Mahmoud Taghizadeh wrote: >3. we are planning to add locale per column for >postgreSQL, but I found that you had said its >impossible. am I right? do you have any paper about >it? > > One of the ways to solve this is to have a special data type for this purpose. Check out the mssqlext project on pgfoundry (http://pgfoundry.org/projects/sql2pg/). In particular, check out the "varcharci" type, that has case preserving varchars. This may provide you with a starting point for what you are trying to do. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/
On Sunday 22 August 2004 07:53, Mahmoud Taghizadeh wrote: > 1. we want to translate some postgreSql documents > (FAQ, tutorial for start). I want to know who is > responsible for this part in postgreSQL (we are from > IRAN) > If you translate the FAQ, make sure it is the html version (http://developer.postgresql.org/cvsweb.cgi/pgsql-server/doc/src/FAQ/FAQ.html). Once you are done you can submit it to pgsql-patches for commital, at which point it should get picked up into the web site. As for the tutorial, you are free to translate that and host it locally, or we could probably make some room up on techdocs if you want. -- Robert Treat Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Sun, 22 Aug 2004, Peter Eisentraut wrote: > To me, this seems completely wrong-headed. Data types should be defined > by what operations you can do on them, not by what output format they > have. I totally agree, lets get rid of money all together. If not, what makes money so special? Do we want other numeric types like hexnumber, octalnamber, weight, length, ... All of these are different ways to format a number in a user interface. Of course one could imaging a system with units, so that if you multiplty two lengths (meter) you get an area (meter^2) and so on.. But it's just going to be complicated and no other programming language I know of have gone that way. -- /Dennis Björklund
On Sun, Aug 22, 2004 at 04:07:17PM -0400, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Tom Lane wrote:
> >> We keep hoping someone will step up to the plate and rewrite it,
> >> instead. Per previous discussion, the type really ought to be a thin
> >> layer over "numeric", with most likely no operations of its own
> >> except I/O conversion.
>
> > And what would it do with it? Add a currency symbol? Which one? Which
> > form? Where? Format the numbers some way?
I'm sure you found answers in "struct lconv" (locale.h), but you'reright (IMHO) better is if datetypes are
independenton format.
What support some argument definition in column definition, somethinglike:
CREATE TABLE tab ( -- curret built-in datetype in/out format num numeric,
-- default user defined format num2 numeric WITH FORMAT,
-- column specific format payme numeric WITH FORMAT='L 999D99', temperature
numeric WITH FORMAT='999D999 C', );
where format producer for datetype is possible (re)define by: CREATE FORMATTER FOR numeric DEFAULT format
INPUTfuncname OUTPUT funcname;
The columns without "FORMAT" options will use standard (current) in/outmethods. Outputs without connection to some
table column can beformated by:
-- curret built-in datetype in/out format SELECT expr;
-- default defined format SELECT FORMAT( expr ); -- specific format SELECT FORMAT( expr AS 'DD/MM/YYYY' );
I think it's pretty extendable solution in contrast to the currenthardcoded in/out datetypes functions.
Comments?
Is there any plan for locale-per-column setting syntax?
> The idea behind the money type is to format per the lc_monetary locale
> setting, which seems perfectly reasonable to me. Further down the road
Why "money" and why not others things like temperature, speed, weight,...?
Karel
-- Karel Zak <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/
On Mon, 23 Aug 2004, Karel Zak wrote: > I think it's pretty extendable solution in contrast to the current > hardcoded in/out datetypes functions. Who are we formatting for? If the client wants the data in a specific format then they can do SELECT to_char(...), or do the formatting in the client all together. If some client wants to render the column value as a bitmap image, let them. We don't need to build in everything a client wants to do in the server. The database should manage data, presenting it to the user in different ways are the job of a client. -- /Dennis Björklund
Dennis Bjorklund wrote: > On Sun, 22 Aug 2004, Peter Eisentraut wrote: > >>To me, this seems completely wrong-headed. Data types should be defined >>by what operations you can do on them, not by what output format they >>have. > > I totally agree, lets get rid of money all together. > > If not, what makes money so special? Do we want other numeric types like > hexnumber, octalnamber, weight, length, ... All of these are different > ways to format a number in a user interface. MONEY seems "odd" because it is interpreting its internal representation based upon locale and the locale is also determining its possible representation, so one database's MONEY isn't really the same type as another database's MONEY. However, Date & Darwen's type model suggests that a database should have support for types like WEIGHT, LENGTH, and TEMPERATURE, although they could certainly be left for the user to define. They define possible representations and THE_ functions as the means to support multiple units (among other purposes.) For example, a LENGTH type would have the following selector functions: LENGTH LENGTH_IN_INCHES(NO_OF_INCHES RATIONAL); LENGTH LENGTH_IN_FEET(NO_OF_FEET RATIONAL); LENGTH LENGTH_IN_CM(NO_OF_CM RATIONAL); Its internal representation would be irrelevant to the user, although the way PostgreSQL's type extensibility system works, it would need to have a default unit. It would also have THE_ functions like: RATIONAL THE_NO_OF_INCHES(LENGTH); RATIONAL THE_NO_OF_FEET(LENGTH); RATIONAL THE_NO_OF_CM(LENGTH); A DISPLAY() function is invoked to display the type in its default representation and if one is not defined, an error occurs in D & D's model. If there must be one, then it would generate unambiguous output like: '8.13 inches' And of course, the various types would be constrained appropriately. One couldn't have a negative LENGTH or a TEMPERATURE under absolute zero, as examples. I think it would be neat to have an external library supporting a large set of types like these. Mike Mascari
On Mon, Aug 23, 2004 at 02:52:44PM +0200, Dennis Bjorklund wrote: > On Mon, 23 Aug 2004, Karel Zak wrote: > > > I think it's pretty extendable solution in contrast to the current > > hardcoded in/out datetypes functions. > > Who are we formatting for? If the client wants the data in a specific > format then they can do SELECT to_char(...), or do the formatting in the > client all together. Yes. But some people call for datetypes with integrated formatting (forexample "money"). I think we should support _common_ way how doformatting (not only for "money") _OR_ we should reject types like"money" and do formatting onlyby extra functions like to_char(). > The database should manage data, presenting it to the user in different > ways are the job of a client. Sure, do you want to read data in binary format that PostgreSQL uses indb files or do you expect it in some nice string?PostgreSQL alreadydoes data formating almost for all datetypes -- see sources anddatetypes in/out functions. Karel -- Karel Zak <zakkr@zf.jcu.cz>http://home.zf.jcu.cz/~zakkr/
On Mon, 2004-08-23 at 14:11, Mike Mascari wrote: ... > MONEY seems "odd" because it is interpreting its internal > representation based upon locale and the locale is also determining > its possible representation, so one database's MONEY isn't really > the same type as another database's MONEY. > > However, Date & Darwen's type model suggests that a database should > have support for types like WEIGHT, LENGTH, and TEMPERATURE, > although they could certainly be left for the user to define. They > define possible representations and THE_ functions as the means to > support multiple units (among other purposes.) For example, a LENGTH > type would have the following selector functions: > > LENGTH LENGTH_IN_INCHES(NO_OF_INCHES RATIONAL); > LENGTH LENGTH_IN_FEET(NO_OF_FEET RATIONAL); > LENGTH LENGTH_IN_CM(NO_OF_CM RATIONAL); The difference between these and money is that there is a constant relationship between units; you may measure a distance in inches or centimetres, but it is always the same distance. The conversions between different units of money vary minute by minute. Furthermore the unit of money is very important, whereas the unit of length is not. You cannot meaningfully add amounts of money in different currencies, even if you convert to some base currency first. -- Oliver Elphick olly@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver GPG: 1024D/A54310EA 92C8 39E7 280E 3631 3F0E 1EC0 5664 7A2F A543 10EA ======================================== "For God hath not appointed us to wrath, but to obtain salvation by our LordJesus Christ, Who died for us, that, whether we wake or sleep, we should live together with him." I Thessalonians 5:9,10