Hi there,
Firstly, I am new to PostgreSQL but installed it recently because of its many
virtues for a project of mine. This is not a bug-report but rather a concern
about the development course of postgresql (hope this is the right place to
post this... please excuse me if it's not).
I am busy
Kilian Hagemann <[EMAIL PROTECTED]> writes:
> After long googling I found that abstime, as was still current in 6.x, would
> do the trick for me. But the 7.x documentation says "You are discouraged from
> using these types in new applications" and that "Any or all of these internal
> types might
>
> Because it will certainly break by 2038, when 32-bit time_t overflows.
>
> In practice, Unix systems will have to move to 64-bit time_t before
> that, and we'll probably either remove abstime or make it an 8-byte type
> as soon as that practice is common.
Thanks for that. By that time my stora
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> Description:Postgres after 7.3.5 does not works on initdb stage
What locale settings are you using?
regards, tom lane
---(end of broadcast)---
TIP 2: you can get o
Tom Lane wrote:
Dave Wilde <[EMAIL PROTECTED]> writes:
I have been having problems with psql under linux lately and this
problem has followed me from
7.4.4 - 7.4.6, but it started sometime after I upgraded to 7.4.4.
It sounds to me like the weirdness is in or around libreadline.
Did you update re
Dave Wilde <[EMAIL PROTECTED]> writes:
> I thought so too, so I looked at ldd for psql and it doesn't link to
> readline, it links to libedit, here's the output. Libedit and readline
> are both at their latest versions, and yes it works great with -n.
Hmm. Maybe latest libedit is broken? (T
-- Originally posted to pgsql-general, but no replies --
I was attempting to set up my psql client on the Win32 version of
postgres 8.0 beta 4 to be able to use an external editor. I set the
environment variable in windows like so:
PSQL_EDITOR="c:\progra~1\Textpa~1\Textpad.exe"
which does appea
Kilian Hagemann wrote:
> >
> > Because it will certainly break by 2038, when 32-bit time_t overflows.
> >
> > In practice, Unix systems will have to move to 64-bit time_t before
> > that, and we'll probably either remove abstime or make it an 8-byte type
> > as soon as that practice is common.
>
>
Compiling on solaris with a non gcc compiler does not correctly enable
debugging when --enable-debug is specified. src/template/solaris is
specifying CFLAGS="-O -v" and -O overrides the -g that --enable-debug
adds.
Kris Jurka
---(end of broadcast)-
This was tested in 7.4.
If you have a table where you declare a column to be
SERIAL, the data type of that column will be set to
type integer (int4).
If you have a table where you declare a column to be
SERIAL8, the data type of that column will be set to
type bigint (int8).
In both cases sequ
elein <[EMAIL PROTECTED]> writes:
> In both cases sequences are created as int8 values with
> a maximum of 9223372036854775807.
> BUG: The assignment of the table containing the int4 column
> will overflow at 2147483648 (max integer size).
I don't think this is really a problem.
You are going t
But shouldn't it wrap when it hits the max?
Assuming wrapping is an OK behavior, not setting
a proper max will eliminate that option for overflow.
--elein
On Wed, Oct 27, 2004 at 08:30:37PM -0400, Tom Lane wrote:
> elein <[EMAIL PROTECTED]> writes:
> > In both cases sequences are created as int8
elein <[EMAIL PROTECTED]> writes:
> But shouldn't it wrap when it hits the max?
No, absolutely not. The default sequence behavior is NO CYCLE, meaning
you'll start getting errors from nextval() when you reach the max.
I don't see a lot of difference between getting that error and getting
an int8-
I'd like to re-raise this bug I reported some time ago and got no response
on. Generally any plain sql commands shouldn't crash the backend and I
don't like a query reporting incorrect results.
On Sun, 27 Jun 2004, Kris Jurka wrote:
> There are problems when a prepared statement's underlying
14 matches
Mail list logo
