On Fri, 26 May 2000, Rainer Mager wrote:
> 1. What happens when the primary key index runs out. That is, if we use an
> INT(4) for a key and we create and delete enough to reach that number then
> what happens?
If you are talking about serial values, then you'll get an error.
Otherwise it's of c
>
> I was thinking about a solution that doesn't cause an overflow. Please
Use 'numeric' datetype. It never overflow and allow you to use deciamal
numbers, but is slowly and is needs more memory.
Karel
> > Hi all,
> >
> > i found a strange behaviour in Postgresql 7.0 on FreeBSD 4.0
> >
> > $ createdb foo
> > $psql foo
> > foo=# create table number (a_number int);
> > foo=# insert into number values(15);
> > foo=# insert into number values(16);
> > select avg(a_number) from numb
On Fri, 26 May 2000, Norbert Meissner wrote:
> Hi all,
>
> i found a strange behaviour in Postgresql 7.0 on FreeBSD 4.0
>
> $ createdb foo
> $psql foo
> foo=# create table number (a_number int);
> foo=# insert into number values(15);
> foo=# insert into number values(16);
> sel
Hi all,
i found a strange behaviour in Postgresql 7.0 on FreeBSD 4.0
$ createdb foo
$psql foo
foo=# create table number (a_number int);
foo=# insert into number values(15);
foo=# insert into number values(16);
select avg(a_number) from number;
avg
-597483648
Th
1. using unsigned int(4), it will take 137 years, inserting one record a second, to
reach MAXINT. That's not an issue, and haven't been handled.
2. Use the curval() function, which returns exactly what you want, and is far better
than reading the sequence table (I don't know if it's standard :
Hello Ian!
Nicolas Huillard proposed the use of cron based scheduling of jobs.
This approach will overload you postgres server.
There is another solution, which I found, will give you the granularity
you will need:
you can combine cron based scheuling with the ability of batch job based
processi
