Wells Oliver wrote:
> Why does this give me two different results? 'created' is a date field:
>
> SELECT * FROM foo WHERE created >= '2013-02-16 00:00:00'::timestamp - INTERVAL
> '24 hours'
test=# select '2013-02-16 00:00:00'::timestamp - INTERVAL '24 hours';
?column?
Wells:
The now() function returns not only the current date, but the current
time. So, now() - 24 hours returns yesterday at this time. But,
yesterday at 00:00:00 is not greater than or equal to yesterday at the
current time (unless, of course, you happened to run this at precisely
00:00:00
Many, many (many) years ago, while working at DIGITAL EQUIPMENT (before it
bellied up), I worked with a relational DB they created called "RDB". Someone
at DEC wrote an sql development gui in Xwindows called "InstantSQL". It was
really great. All the tables of the DB were icons, you could dra
John Shott writes:
> I believe that if you use the current_date function, instead of now(),
> and subtract 24 hours from that, then you will get the behavior that you
> expect.
If you're working with dates, rather than timestamps, it's even easier
than that: just add or subtract an integer.
re
Gauthier, Dave wrote on 16.02.2013 17:04:
Many, many (many) years ago, while working at DIGITAL EQUIPMENT
(before it bellied up), I worked with a relational DB they created
called "RDB".
RDB/VMS was actually the first relational database I ever worked with.
Boy, is that a long time ago...
Hi,
A bulk import (script attached) is failing.
Error message:
psql:/home/andyt/projects/django-stringer/txc/stops_inport.txt:86: ERROR:
invalid input syntax for type double precision: "stop_lat"
I think the reason may be a delimiters in strings such as "Golders Green,
Golders Green, stop GW"
On 02/16/2013 09:02 AM, Andrew Taylor wrote:
Hi,
A bulk import (script attached) is failing.
Error message:
psql:/home/andyt/projects/django-stringer/txc/stops_inport.txt:86:
ERROR: invalid input syntax for type double precision: "stop_lat"
I think the reason may be a delimiters in strings su
The first value seems more suspect, should be "490015496GW". Mixing
numeric and string values is best enclosed in quotes.
"Golders Green, Golders Green, stop GW" is normal if you want the
entire string between the quotes to arrive in a single column (with
the comma).
On Sat, 2013-02-16 at 17
Unfortunately my starting point is data in the format of that example line.
I hasn't spotted the lack of quotes on the first value. Given this format,
is my best bet to write a script transforming it pre-import to postgres?
I.e. are there no arguments I could pass to the import process to handle
th
On 02/16/2013 09:52 AM, Andrew Taylor wrote:
Unfortunately my starting point is data in the format of that example
line. I hasn't spotted the lack of quotes on the first value. Given this
format, is my best bet to write a script transforming it pre-import to
postgres? I.e. are there no arguments
On 02/16/2013 09:52 AM, Andrew Taylor wrote:
Unfortunately my starting point is data in the format of that example
line. I hasn't spotted the lack of quotes on the first value. Given this
format, is my best bet to write a script transforming it pre-import to
postgres? I.e. are there no arguments
On 02/16/2013 09:52 AM, Andrew Taylor wrote:
Unfortunately my starting point is data in the format of that example
line. I hasn't spotted the lack of quotes on the first value. Given this
format, is my best bet to write a script transforming it pre-import to
postgres? I.e. are there no arguments
David Kerr wrote:
> Also, if anyone else stumbles upon this, it only seems to happen with jruby.
> I have standard ruby programs where this does not occur.
It sounds like it is at least possible that it is the issue I described here:
http://www.postgresql.org/message-id/4afbe87202250002c..
13 matches
Mail list logo
