On Sun, 6 Feb 2005, Tom Lane wrote:
> Kris Jurka <[EMAIL PROTECTED]> writes:
> > The documentation says the time with time zone datatype allows zone
> > offsets from +12 to -12.
>
> I see noplace that opines on this at all ...
>
http://www.postgresql.org/docs/8.0/static/datatype-datetime.htm
How come this work in pg (8.0 and older):
CREATE TABLE bug (x int);
SELECT count(bug) FROM bug;
Shouldn't it complain and say that "bug" is not a column?
--
/Dennis Björklund
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> How come this work in pg (8.0 and older):
> CREATE TABLE bug (x int);
> SELECT count(bug) FROM bug;
> Shouldn't it complain and say that "bug" is not a column?
No. This is a perfectly good, if somewhat historical, spelling of
SELECT cou
Hi All,
I've been getting these errors ("ERROR: cache lookup failed for
relation 17442") in my logs for a while now. It originally seemed
like a hardware problem, however now we getting them pretty consistently
on a couple servers. I've scalled down the schema to the one table and
the funct
Michael Guerin <[EMAIL PROTECTED]> writes:
> I've been getting these errors ("ERROR: cache lookup failed for
> relation 17442") in my logs for a while now.
Turning on verbose error logging shows that the error invariably comes
from RelationIsVisible():
2005-02-07 16:44:35 EST 2994 ERROR: X
Also ... the visibility issue doesn't seem to explain the other symptom
you reported:
> With the original function, the log messages were slightly different and
> usually caused the server to reset:
> ERROR: duplicate key violates unique constraint
> "pg_type_typname_nsp_index"
What was the "ori
Michael Guerin wrote:
Hi All,
I've been getting these errors ("ERROR: cache lookup failed for
relation 17442") in my logs for a while now. It originally seemed
like a hardware problem, however now we getting them pretty consistently
on a couple servers. I've scalled down the schema to the o
On Mon, Feb 07, 2005 at 05:07:47PM -0500, Tom Lane wrote:
> A more general issue is that we now have a pile of "catalog inquiry"
> functions that all make use of backend internal lookups and therefore
> reflect SnapshotNow behavior to the user. This has bothered me for
> some
> time,
Can we pass
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Mon, Feb 07, 2005 at 05:07:47PM -0500, Tom Lane wrote:
>> A more general issue is that we now have a pile of "catalog inquiry"
>> functions that all make use of backend internal lookups and therefore
>> reflect SnapshotNow behavior to the user.
> Can
Tom Lane wrote:
Also ... the visibility issue doesn't seem to explain the other symptom
you reported:
With the original function, the log messages were slightly different and
usually caused the server to reset:
ERROR: duplicate key violates unique constraint
"pg_type_typname_nsp_index"
Wha
Michael Guerin <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> What was the "original function" exactly?
>>
> It's included in the schema call uspgetcompositeids2_orig. The only
> differences is that this function creates and drops the temp table
> within the function, the newer function keep
Tom Lane wrote:
Michael Guerin <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
What was the "original function" exactly?
It's included in the schema call uspgetcompositeids2_orig. The only
differences is that this function creates and drops the temp table
within the function, the new
Create a trigger using capitalized letters. Whenever you select the trigger,
the name of the trigger appears without quotes.
lucas galfaso
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
The following bug has been logged online:
Bug reference: 1469
Logged by: Anthony COMMUNIER
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: Aix 5.2,UnixWare 7.1.3,Win32
Description:ECPG : Can't delete an item pointed by a cursor
Details:
The following bug has been logged online:
Bug reference: 1463
Logged by: Vojtech Rysanek
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system: Windows
Description:Borland C++ problem
Details:
Hello,
the compiling Borland C++ .lib and .dlls does
The following bug has been logged online:
Bug reference: 1467
Logged by: Florian Hars
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: All
Description:fe_connect doesn't handle EINTR right
Details:
The file pgsql/src/interfaces/libpq/fe-c
Hi All,
I've been getting these errors ("ERROR: cache lookup failed for
relation 17442") in my logs for a while now. It originally seemed
like a hardware problem, however now we getting them pretty consistently
on a couple servers. I've scalled down the schema to the one table and
the fu
The following bug has been logged online:
Bug reference: 1462
Logged by: Vladimir
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8
Operating system: Windows2k sp4
Description:install bug
Details:
when installing PostgreSQL 8 and choose folder for installation
The following bug has been logged online:
Bug reference: 1465
Logged by: Manlio Perillo
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.0
Operating system: Windows XP
Description:UTF-8 BOM
Details:
psql client program on Windows does not recognize UTF-8 BOM
The following bug has been logged online:
Bug reference: 1468
Logged by: Tobias Brox
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.0
Operating system: Linux, gentoo
Description:psql_dump is not backward compatible
Details:
I have a situation where my peer
Hi!
Our upgrade from 7.4.6 to 8.0.1 only had one small glitch. Two tables
got dumped in the wrong order (before their dependecies) and had to get
their contents added manually after the restore. I've atleast isolated
the part where things go wrong.
Two files are attached, related as follows (al
I've also come across this in 7.4. You could also use:
SELECT NULL AS Test
UNION ALL SELECT NULL::int
UNION ALL SELECT 0
Dirk
Tom Lane wrote:
"" <[EMAIL PROTECTED]> writes:
The following query should not raise an error ("ERROR: UNION types text and
integer cannot be matched"):
SELECT
Tom Lane, 2005-02-01 04:45 GMT +01:00, wrote:
Rolf Sponsel <[EMAIL PROTECTED]> writes:
From my understanding, the preferred way
for Solaris is to only set LD_RUN_PATH,
and avoid setting LD_LIBRARY_PATH, at
link-time. This is what I usually do.
And usually works very well.
No, the preferred thing is
Okay, I've now succeeded to build with
default runtime paths built/linked in,
although not using the optimal solution
(see end of this message).
Please see further comments in-lined below ...
Rolf Sponsel, 2005-02-04 23:26 GMT +01:00, wrote:
Tom Lane, 2005-02-01 04:45 GMT +01:00, wrote:
Rolf Sponse
Hi!
Had a curious problem with postgresql 7.0.3. Could create a DB if I run
kernel 2.4 but not in 2.6. Had a look in
/src/backend/commands/dbcommands.c and finaly found out that you use an
errorounous ret value from the system()-call. You checked for: if
(system(buf) != 0)
.. I changed those lin
The following bug has been logged online:
Bug reference: 1466
Logged by: Joe Brown
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.0.0
Operating system: Windows XP
Description:#maintenace_work_mem = 16384
Details:
I was attempting to reduce the already tiny
The following bug has been logged online:
Bug reference: 1460
Logged by: Daniel
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: win 2000
Description:unable dwonloads
Details:
An error has occurred processing the request...
Unable to
Peter Eisentraut schrieb:
Am Donnerstag, 3. Februar 2005 16:11 schrieb Rainer Frey:
A select should not lock a table even when it is not committed.
The SELECT obtains a read (shared) lock on the table, but the ALTER TABLE
requires a write (exclusive) lock. This is certainly necessary because you
28 matches
Mail list logo
