Re: [GENERAL] Where Can I Find...

2013-01-26 Thread John R Pierce
On 1/25/2013 8:21 AM, Gene Poole wrote: lso I don't want to use RPM because I like to control where software is installed. Another piece on information is that I am running on CentOS 5.8. if you don't want to use RPM, why did you choose an RPM based distribution? is '6 single sided DVDs'

Re: [GENERAL] Postfresql 8.4 Problem

2013-01-26 Thread Pavel Stehule
Hello what did you do exactly? please, can you send more details? https://wiki.postgresql.org/wiki/Guide_to_reporting_problems Regards Pavel Stehule 2013/1/25 Electric Boy : > I have a problem with posgresql 8.4, yesterday when I tried to reinstall and > do restore the old database not work

Re: [GENERAL] date_trunc to aggregate by timestamp?

2013-01-26 Thread Jasen Betts
On 2013-01-24, Kirk Wythers wrote: > I am trying to some up with an approach that uses "date_truc" to > aggregate 15 minute time series data to hourly bins. My current query > which utilizes a view, does performs a join after which I use a series a > WHERE statements to specify which of the 15

Re: [GENERAL] Can LC_TIME affect timestamp input?

2013-01-26 Thread Jasen Betts
On 2013-01-25, Paul Jones wrote: > Is it possible for LC_TIME locale to affect the format with which > timestamps are input? > I have DB2 CSV dumps with timestamps like '2003-10-21-22.59.44.00' All the non-digit symbols between "21" and the "44" look unusual > that I want to load into Postg

Re: [GENERAL] Temporary schemas

2013-01-26 Thread pamkiki
Thanks! very useful for me! -- View this message in context: http://postgresql.1045698.n5.nabble.com/Temporary-schemas-tp3244865p5742352.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make

Re: [GENERAL] Cast double precision to integer & check for overflow

2013-01-26 Thread Jasen Betts
On 2013-01-26, Ian Pilcher wrote: > I need to cast a double precision into an integer, and I want to check > that the value will actually fit (modulo rounding). > > Coming from a C/Java background, this seems like something that should > be utterly trivial. In my searching, however, I can't seem

[GENERAL] Postfresql 8.4 Problem

2013-01-26 Thread Electric Boy
I have a problem with posgresql 8.4, yesterday when I tried to reinstall and do restore the old database not work if you install in a different folder than the folder given the old database, the program works. When installing program the old folder where the database service postgresql not start

Re: [GENERAL] Running update in chunks?

2013-01-26 Thread Tim Uckun
> > That would be one solution, but I think a better one would be to not > store "make_id" in "imports" in the first place, but instead to always > fetch it by joining "imports" to "models" at query time. > My problem here is that the incoming data is quite messy so the join conditions become weir

Re: [GENERAL] Cast double precision to integer & check for overflow

2013-01-26 Thread Adrian Klaver
On 01/26/2013 03:09 PM, Ian Pilcher wrote: On 01/26/2013 05:06 PM, Alexander Gataric wrote: Just cast to integer. Decimal portion will be lost. That part I've got. :-) It's checking that the double precision value will actual fit within the range of the integer type (-2147483648 to +21474836

Re: [GENERAL] Cast double precision to integer & check for overflow

2013-01-26 Thread Gavan Schneider
On Saturday, January 26, 2013 at 08:13, Ian Pilcher wrote: I need to cast a double precision into an integer, and I want to check that the value will actually fit (modulo rounding). Coming from a C/Java background, this seems like something that should be utterly trivial. In my searching, howe

Re: [GENERAL] Cast double precision to integer & check for overflow

2013-01-26 Thread Ian Pilcher
On 01/26/2013 05:06 PM, Alexander Gataric wrote: > Just cast to integer. Decimal portion will be lost. That part I've got. :-) It's checking that the double precision value will actual fit within the range of the integer type (-2147483648 to +2147483647). I could certainly hard-code these value

[GENERAL] Re: [GENERAL] Cast double precision to integer & check for overflow

2013-01-26 Thread Alexander Gataric
Just cast to integer. Decimal portion will be lost. Sent from my smartphone - Reply message - From: "Ian Pilcher" To: Subject: [GENERAL] Cast double precision to integer & check for overflow Date: Sat, Jan 26, 2013 3:13 pm I need to cast a double precision into an integer, and I want

[GENERAL] Cast double precision to integer & check for overflow

2013-01-26 Thread Ian Pilcher
I need to cast a double precision into an integer, and I want to check that the value will actually fit (modulo rounding). Coming from a C/Java background, this seems like something that should be utterly trivial. In my searching, however, I can't seem to find any SQL equivalent of INT_MAX, Integ

Re: [GENERAL] Range for user-defined SQLSTATE codes

2013-01-26 Thread Tom Lane
Kevin Grittner writes: > Ian Pilcher wrote: >> Is there anything like a standard range -- formal or otherwise -- for >> such codes? A best practice? A general consensus? A half-painted >> bike shed? > There is this in the SQL standard. According to that, SQLSTATE > values with 0-4 or A-H in

Re: [GENERAL] Range for user-defined SQLSTATE codes

2013-01-26 Thread Kevin Grittner
Ian Pilcher wrote: > I can't be the first person (or even the 10,000th) to want to define my > own SQLSTATE codes when raising errors in a stored procedure.  I've > just tested doing so in a PL/pgSQL function access via JDBC, and I had > no problem retrieving the non-standard state from the SQLEx

Re: [GENERAL] self join for history analyzis

2013-01-26 Thread Rafał Pietrak
W dniu 01/26/2013 02:49 PM, Alban Hertroys pisze: On Jan 26, 2013, at 13:32, Rafał Pietrak wrote: I have a usage recording table: CREATE TABLE readings(tm timestamp, bytesin int, bytesout int); The readouts are made "occasionally" - the timespan between the readouts are not very precise, bu

Re: [GENERAL] self join for history analyzis

2013-01-26 Thread Alban Hertroys
On Jan 26, 2013, at 13:32, Rafał Pietrak wrote: > I have a usage recording table: CREATE TABLE readings(tm timestamp, bytesin > int, bytesout int); > > The readouts are made "occasionally" - the timespan between the readouts are > not very precise, but there is a lot of those readouts. > > wh

[GENERAL] self join for history analyzis

2013-01-26 Thread Rafał Pietrak
Hello the list, For some time now, I'm struggling with a problem of self join of a table: I have a usage recording table: CREATE TABLE readings(tm timestamp, bytesin int, bytesout int); The readouts are made "occasionally" - the timespan between the readouts are not very precise, but there i