Re: [BUGS] No migration path for MONEY
On Tue, Jan 28, 2003 at 08:24:13PM +0100, Peter Eisentraut wrote: > Bruce Momjian writes: > > > we need someone to get MONEY working as an extented NUMERIC type. > > How would the new "money" be different from "numeric"? If we have > "money", should we have "length", "mass", and "temperature"? I think not. > Just let the money type die and that's it. Agree. BTW, the correct "money" implementation is very depend on locales, for example the current implementation is not usable in my country and our currency. It must be very powerful, an example like strfmon() in libc. I think numeric and to_char() is useful already now. Karel -- Karel Zak <[EMAIL PROTECTED]> http://home.zf.jcu.cz/~zakkr/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] [pgsql-bugs] Daily Digest V1 #784
On Tue, Jan 28, 2003 at 17:47:14 -0500, tom lane wrote: [...] > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > How would the new "money" be different from "numeric"? > > [ temporarily re-dons currency-trader hat... ] > > What would actually be useful is a money type that carries along an > indication of which currency the amount is expressed in (not per-column > as Bruce naively suggested, but right in the datum). This would allow > conversions to be performed between different currencies, as well as > allowing the correct decoration to be provided on output. Exactly. Except that for currency, you'd have to carry a timestamp along with the units -- the conversion factor between meters and inches is more or les constant, but the one between USD and YEN, say not. Come to think of it, even the point in time isn't enough (I remember times where you got more Deutsche Mark for an US dollar in the Soviet Union than you got in Western Germany). Oh, well... > > If we have "money", should we have "length", "mass", and > > "temperature"? I think not. > > Physicists have found use for numeric objects that carry along an > indication of the units they're in --- in other words, not "length" etc, > but a generic "measurement" type that might tag its value as "meters" or > "kilograms" or "furlongs per fortnight". It's an interesting idea, "magnitude-plus-unit" (note that the magnitude itself could be a vector or a tuple). I had the same idea thinking of the currency problem. But to tackle the currency problem you need a notion of `complex units' (like `currency-plus-timestamp', if we want to be simplistic). Regards -- tomas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] No migration path for MONEY
The problem here is not that we are getting rid of MONEY as datatype, (I see
no need for it with having numeric) the problem comes from haveing no way to
migrate MONEY to NUMERIC short of hand editing the pgdump file and then
reimporting. Yes I know I can use sed, but that is not the point. In 7.1
and prior I could do a SELECT '1.0'::MONEY::TEXT or to NUMERIC or to FLOAT
even.
On Monday 27 January 2003 12:06, Bruce Momjian wrote:
> They are probably better off just changing the column data type, _and_
> we need someone to get MONEY working as an extented NUMERIC type.
>
> ---
>
> Josh Berkus wrote:
> > Folks,
> >
> > Bug reported off IRC:
> >
> > MONEY Type cannot be cast to any other type, preventing migration from
> > this depreciated data type.
> >
> > Affects: 7.2.3, 7.3.1
> > Frequency: 100% Reproducable
> > Effect When Occurring: Unable to convert, query data
> > Difficulty of Fix: Easy, probably
> > Certianty of Diagnosis: 100%
> >
> > On both 7.2.3 and 7.3.1 all of the following statements will fail:
> >
> > select cast('40.00'::MONEY as NUMERIC);
> > select cast('40.00'::MONEY as DOUBLE);
> > select cast('40.00'::MONEY as VARCHAR);
> > select "numeric"('40.00'::MONEY);
> > select to_char('40.00'::MONEY, '999.');
> >
> > This means that someone who has inherited or upgarded a 6.5 database with
> > MONEY columns has no way to migrate them to NUMERIC columns other than an
> > external language script or dump and reload from COPY file.
> >
> > I propose that we need to restore the CAST(MONEY AS NUMERIC) function so
> > that users can migrate old databases to the new data type. In later
> > versions of postgres, I suggest that MONEY be abandoned as a true data
> > type and instead become a DOMAIN of NUMERIC for those converting.
> >
> > --
> > -Josh Berkus
> > Aglio Database Solutions
> > San Francisco
> >
> >
> > ---(end of broadcast)---
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.org
--
Darcy Buskermolen
Wavefire Technologies Corp.
ph: 250.717.0200
fx: 250.763.1759
http://www.wavefire.com
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] No migration path for MONEY
Darcy Buskermolen <[EMAIL PROTECTED]> writes: > In 7.1 and prior I could do a SELECT '1.0'::MONEY::TEXT or to NUMERIC > or to FLOAT even. No, you couldn't. regression=# SELECT '1.0'::MONEY::TEXT ; ERROR: Cannot cast type 'money' to 'text' regression=# select version(); version -- PostgreSQL 7.1.3 on hppa2.0-hp-hpux10.20, compiled by GCC 2.95.3 (1 row) 7.0 is the same. 7.2 is the same. 7.3 is the same except it doesn't put quotes in the error message ;-) It might be worth adding some conversion functions in the future --- but don't assert that we've removed such, because we have not. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] No migration path for MONEY
Sorry my mistake on versions. darcy=> SELECT '1.0'::MONEY::FLOAT; ?column? 1 (1 row) darcy=> SELECT '1.0'::MONEY::TEXT; ?column? 1.0 (1 row) darcy=> select version(); version PostgreSQL 6.5.2 on i386-unknown-freebsd3.2, compiled by gcc 2.7.2.1 (1 row) On Wednesday 29 January 2003 09:04, Tom Lane wrote: > Darcy Buskermolen <[EMAIL PROTECTED]> writes: > > In 7.1 and prior I could do a SELECT '1.0'::MONEY::TEXT or to NUMERIC > > or to FLOAT even. > > No, you couldn't. > > regression=# SELECT '1.0'::MONEY::TEXT ; > ERROR: Cannot cast type 'money' to 'text' > regression=# select version(); > version > -- > PostgreSQL 7.1.3 on hppa2.0-hp-hpux10.20, compiled by GCC 2.95.3 > (1 row) > > 7.0 is the same. 7.2 is the same. 7.3 is the same except it doesn't > put quotes in the error message ;-) > > It might be worth adding some conversion functions in the future --- > but don't assert that we've removed such, because we have not. > > regards, tom lane > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] No migration path for MONEY
Darcy Buskermolen <[EMAIL PROTECTED]> writes: > Sorry my mistake on versions. > darcy=> SELECT '1.0'::MONEY::FLOAT; > ?column? > >1 > (1 row) > darcy=> select version(); > version > > PostgreSQL 6.5.2 on i386-unknown-freebsd3.2, compiled by gcc 2.7.2.1 > (1 row) I don't have a 6.5 system around to test anymore, but my recollection is that back then, constructs like 'literal'::foo::bar were collapsed into 'literal'::bar --- so the above doesn't prove 6.5 could actually convert money into float. What happens if you take a money column and try to coerce it, ie "SELECT moneycol::float FROM mytable" ? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] No migration path for MONEY
Tom you are correct here (like usual), sorry for the wasted thread and time regarding functions that I remembered being there but infact were not. On Wednesday 29 January 2003 10:56, Tom Lane wrote: > Darcy Buskermolen <[EMAIL PROTECTED]> writes: > > Sorry my mistake on versions. > > darcy=> SELECT '1.0'::MONEY::FLOAT; > > ?column? > > > >1 > > (1 row) > > darcy=> select version(); > > version > > > > PostgreSQL 6.5.2 on i386-unknown-freebsd3.2, compiled by gcc 2.7.2.1 > > (1 row) > > I don't have a 6.5 system around to test anymore, but my recollection is > that back then, constructs like 'literal'::foo::bar were collapsed into > 'literal'::bar --- so the above doesn't prove 6.5 could actually convert > money into float. What happens if you take a money column and try to > coerce it, ie "SELECT moneycol::float FROM mytable" ? > > regards, tom lane > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] Bug #889: PQconnectdb SEGV
Chris Brown ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
PQconnectdb SEGV
Long Description
In the libpq C interface, PQconnectdb results in a SEGV when the conn->sock number is
greater than __FD_SETSIZE (1024 on linux). The crash is caused by stack corruption
when attempting to FD_SET.
Solution: switch to poll() whenever that is available. Example code is a unified
diff. It needs some cleaning, and autoconf work, but the bulk of the code is written.
Also, this patch is still being tested, but after 24hrs has held up without crashing.
If possible, I would like to know which version of PG this is likely to go in to (in
whatever form it takes).
Side Note: pqWriteReady and pqReadReady could simply be calls to pqWait. I didn't
code it that way to minimize impact. That change would reduce the number of code
paths to test.
Sample Code
diff -ru postgresql-7.3.orig/src/interfaces/libpq/fe-misc.c
postgresql-7.3.poll/src/interfaces/libpq/fe-misc.c
--- postgresql-7.3.orig/src/interfaces/libpq/fe-misc.c Thu Oct 24 16:35:55 2002
+++ postgresql-7.3.poll/src/interfaces/libpq/fe-misc.c Wed Jan 29 12:11:47 2003
@@ -43,9 +43,13 @@
#include
#endif
+#if USE_SELECT_INSTEAD_OF_POLL // {
#ifdef HAVE_SYS_SELECT_H
#include
#endif
+#else // }{ if USE_SELECT_INSTEAD_OF_POLL
+#include
+#endif // } if USE_SELECT_INSTEAD_OF_POLL else
#include "libpq-fe.h"
#include "libpq-int.h"
@@ -350,6 +354,8 @@
return 0;
}
+
+#if USE_SELECT_INSTEAD_OF_POLL // {
/*
* pqReadReady: is select() saying the file is ready to read?
* JAB: -or- if SSL is enabled and used, is it buffering bytes?
@@ -426,6 +432,107 @@
}
return FD_ISSET(conn->sock, &input_mask) ? 1 : 0;
}
+#else // }{ if USE_SELECT_INSTEAD_OF_POLL
+/*
+ * pqReadReady: is poll() saying the file is ready to read?
+ * JAB: -or- if SSL is enabled and used, is it buffering bytes?
+ * Returns -1 on failure, 0 if not ready, 1 if ready.
+ */
+int
+pqReadReady(PGconn *conn)
+{
+ struct pollfd input_fd;
+
+ if (!conn || conn->sock < 0)
+ return -1;
+
+/* JAB: Check for SSL library buffering read bytes */
+#ifdef USE_SSL
+ if (conn->ssl && SSL_pending(conn->ssl) > 0)
+ {
+ /* short-circuit the select */
+ return 1;
+ }
+#endif
+
+ input_fd.fd = conn->sock;
+ input_fd.events = POLLIN;
+ input_fd.revents = 0;
+
+ while ( poll( &input_fd, 1, -1 ) < 0 )
+ {
+ if ( SOCK_ERRNO == EINTR )
+ {
+ /* Interrupted system call - we'll just try again */
+ continue;
+ }
+
+ printfPQExpBuffer(&conn->errorMessage,
+ libpq_gettext("poll() failed: %s\n"),
+ SOCK_STRERROR(SOCK_ERRNO));
+ return -1;
+ }
+
+ if ( input_fd.revents | POLLIN )
+ {
+ return 1;
+ }
+ else
+ {
+ return 0;
+ }
+}
+
+/*
+ * pqWriteReady: is poll() saying the file is ready to write?
+ * Returns -1 on failure, 0 if not ready, 1 if ready.
+ */
+int
+pqWriteReady(PGconn *conn)
+{
+ struct pollfd input_fd;
+
+ if (!conn || conn->sock < 0)
+ return -1;
+
+/* JAB: Check for SSL library buffering read bytes */
+#ifdef USE_SSL
+ if (conn->ssl && SSL_pending(conn->ssl) > 0)
+ {
+ /* short-circuit the select */
+ return 1;
+ }
+#endif
+
+ input_fd.fd = conn->sock;
+ input_fd.events = POLLOUT;
+ input_fd.revents = 0;
+
+ while ( poll( &input_fd, 1, -1 ) < 0 )
+ {
+ if ( SOCK_ERRNO == EINTR )
+ {
+ /* Interrupted system call - we'll just try again */
+ continue;
+ }
+
+ printfPQExpBuffer(&conn->errorMessage,
+ libpq_gettext("poll() failed: %s\n"),
+ SOCK_STRERROR(SOCK_ERRNO));
+ return -1;
+ }
+
+ if ( input_fd.revents | POLLOUT )
+ {
+ return 1;
+ }
+ else
+ {
+ return 0;
+ }
+}
+#endif // } if USE_SELECT_INSTEAD_OF_POLL else
+
/* --
* pqReadData: read more data, if any is available
@@ -782,6 +889,8 @@
return pqWaitTimed(forRead, forWrite, conn, (time_t) -1);
}
+
+#if USE_SELECT_INSTEAD_OF_POLL // {
/*
* pqWaitTimed: wait, but not past finish_time.
*
@@ -867,7 +976,100 @@
return 0;
}
+#else // }{ if USE_SELECT_INSTEAD_OF_POLL
+/*
+ * pqWaitTimed: wait, but not past finish_time.
+ *
+ * If finish_time is exceeded then we return failure (EOF). This is different
+ * from the response for a kernel exception (return 0)
Re: [BUGS] Bug #889: PQconnectdb SEGV
[EMAIL PROTECTED] writes: > In the libpq C interface, PQconnectdb results in a SEGV when the conn->sock number >is greater than __FD_SETSIZE (1024 on linux). The crash is caused by stack >corruption when attempting to FD_SET. Shouldn't you be filing this bug against libc? Seems to me the left hand is not talking to the right hand, if open() can return FDs that don't work with select(). regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
