-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I want to set a session id based on a session timeout per user. I
> have a very large logfile with more than 1.3 Mio records and look
> for a very efficient solution - maybe with PL/pgSQL .
Can you post a clearer example with the exact columns
Sweeet!
This is what I ended up with:
create domain testdate char(10) check (VALUE::text::date = VALUE);
(it wasn't possible to insert a NULL date with (VALUE::text::date IS NOT
NULL); )
I'm pretty happy with this as I didn't even have to use
to_char(VALUE::text::date , '-MM-DD') for t
Dear Users,
I am very new to using the inet data type and I have a
database with a list of CIDRs in it
And I was hoping to be able to do some kind of select
statement that would pull the record
That the IP given is located in for example. If in my
database I have a record like:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hallo,
ich habe in einer Tabelle eine Spalte mit dem Datentyp text, das ich nach
bytea wandeln möchte (um später auch \000 speichern zu können).
Direkt scheint ein Alter Table da nicht zu gehen, also lege ich eine
temporäre Spalte an.
Nur:
> UPDA
On Tuesday, Dec 2, 2003, at 03:53 US/Pacific, Alexander M. Pravking
wrote:
On Mon, Dec 01, 2003 at 09:09:20PM -0800, Bob Smith wrote:
I'm getting an unexpected result using intervals in an expression:
select ('2003-10-26 0:00:00'::timestamp + '1 day'::interval)::date;
date
2003
On Tue, 2 Dec 2003, Iain wrote:
> T've been following this thread with interest because I have a related
> problem. Basically we are storing dates in CHAR fields with al the
> associated problems. I'd like to do it, but changing everything to date
> fields isn't practical for now, so as a stopgap
>
> My machine just crashed in the middle of an update.
>
> When I restart the postgresql server the database engine appears ok and the=
> n tells me that a file /data/pg_clog/0697 is not there.=20
>
> I presume that these are the transaction log files.=20
> I would like to truncate the old logf
Bob Smith <[EMAIL PROTECTED]> writes:
> '1 day' just means '24 hours'
Yup.
> Is this a Postgres bug, or is this correct SQL behavior?
It's arguably a bug, but it's unfixable without a significant change in
the internal representation and handling of intervals. I don't know
when anyone will get
On Mon, Dec 01, 2003 at 09:09:20PM -0800, Bob Smith wrote:
> I'm getting an unexpected result using intervals in an expression:
>
> select ('2003-10-26 0:00:00'::timestamp + '1 day'::interval)::date;
> date
>
> 2003-10-26
> (1 row)
Try using '2003-10-26 0:00:00'::date + 1;
integ
On Tue, Dec 02, 2003 at 01:55:06PM +0300, Alexander M. Pravking wrote:
> Try using check (VALUE::text::date).
Assuming check expects boolean result, it's (VALUE::text::date IS NOT NULL)
--
Fduch M. Pravking
---(end of broadcast)---
TIP 4: Don't '
On Tue, Dec 02, 2003 at 07:44:54PM +0900, Iain wrote:
> T've been following this thread with interest because I have a related
> problem. Basically we are storing dates in CHAR fields with al the
> associated problems. I'd like to do it, but changing everything to date
> fields isn't practical for
T've been following this thread with interest because I have a related
problem. Basically we are storing dates in CHAR fields with al the
associated problems. I'd like to do it, but changing everything to date
fields isn't practical for now, so as a stopgap solution, I want to provide
some validati
On Tue, Dec 02, 2003 at 10:57:14AM +0100, Karel Zak wrote:
> > > If not, has something changed in 7.4?
>
> No change in 7.4. Maybe in 7.5 or in some 7.4.x.
Well, let's see.
> The others PostgreSQL stuff which full parse (means check ranges)
> date/time is less optimistic with this:
>
> # se
On Tue, Dec 02, 2003 at 10:27:04AM +0100, Christoph Haller wrote:
> As far as I know these results are correct in terms of the underlying
> C-library function mktime(). This function is intended to be used when
> adding/subtracting intervals from a given timestamp.
Which one? mktime() or to_dat
On Tue, Dec 02, 2003 at 10:27:04AM +0100, Christoph Haller wrote:
> >
> > I just discovered that to_date() function does not check if supplied
> > date is correct, giving surprising (at least for me) results:
> >
> > fduch=# SELECT to_date('31.11.2003', 'DD.MM.');
> > to_date
> > --
>
> I just discovered that to_date() function does not check if supplied
> date is correct, giving surprising (at least for me) results:
>
> fduch=# SELECT to_date('31.11.2003', 'DD.MM.');
> to_date
>
> 2003-12-01
>
> or even
>
> fduch=# SELECT to_date('123.45.2003', 'DD.MM.
On Tuesday 02 December 2003 05:09, Bob Smith wrote:
> I'm getting an unexpected result using intervals in an expression:
>
> select ('2003-10-26 0:00:00'::timestamp + '1 day'::interval)::date;
> date
>
> 2003-10-26
> I assumed '1 day' would always increment the date by 1, but i
17 matches
Mail list logo
