I'm trying to implement some code to recreate tables as we discussed
formerly. But it's not so easy... :-) My first blind alley is that
dropping a function which is occured in a CHECK constraint or
a DEFAULT constraint, I get fmgr_info: function 12345678: cache
lookup failed or Function OID
On Tue, 28 May 2002, Tom Lane wrote:
Kovacs Zoltan [EMAIL PROTECTED] writes:
I'm trying to implement some code to recreate tables as we discussed
formerly. But it's not so easy... :-) My first blind alley is that
dropping a function which is occured in a CHECK constraint or
a DEFAULT
I cannot use RULEs with WHERE clauses. What's wrong? Is this a bug? I also
had this problem with 7.1.1. The documentation says this should work.
foo=# SELECT version();
version
-
PostgreSQL 7.1.3
For me it seems to be slow due to the sorting. Is this right?
Is this normal at all? Is it possible to make it faster?
If you know, that your result does not produce duplicates
(which are filtered away with union) you can use a
union all which should be substantially faster, since it
I experienced that UNIONs in 7.1.1 are rather slow:
tir=# explain (select nev from cikk) union (select tevekenyseg from log);
NOTICE: QUERY PLAN:
Unique (cost=667.63..687.18 rows=782 width=12)
- Sort (cost=667.63..667.63 rows=7817 width=12)
- Append (cost=0.00..162.17 rows=7817
After more than 3 months of hard testing I found a small bug in
PLPGSQL. (It works _too_ fine due to your excellent work... :-) Thanks!)
Consider this function:
CREATE FUNCTION testfunc () RETURNS int4 AS '
declare
ret int4;
begin
ret := column1 FROM table WHERE column2 LIKE ''%anything%''
On Thu, 10 May 2001, Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
Can anyone suggest why this might be happening (I think it's in 7.1b4):
Can't duplicate in current sources:
regression=# SELECT definition as viewdef,
regression-# (select oid from pg_rewrite where
On Fri, 11 May 2001, Philip Warner wrote:
Can anyone suggest why this might be happening (I think it's in 7.1b4):
SELECT definition as viewdef,
(select oid from pg_rewrite where
rulename='_RETszallitolevel_tetele_ervenyes') as view_oid
from pg_views where
You're welcome ;-)
Marvellous, it works! How much time did it take for you to find what have
to be changed?
Thank you very much.
Regards, Zoltan
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Date: Fri, 16 Mar 2001 22:58:42 +1100
From: Philip Warner [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: I cannot force pg_dump to disable triggers
At 12:49 16/03/01 +0100, kovacsz wrote:
I downloaded the current snapshot and realized that you changed the
dumping behaviour about
On Tue, 8 May 2001, Tom Lane wrote:
Kovacs Zoltan [EMAIL PROTECTED] writes:
I cannot decide if this is a serious bug or not --- some queries from
complex views may give strange results. The next few days I will try to
find the point where the problem is but now I can only include the data
Hi,
I cannot decide if this is a serious bug or not --- some queries from
complex views may give strange results. The next few days I will try to
find the point where the problem is but now I can only include the data
structure and the SELECT statements which don't give the correct result. A
lot
On Wed, 2 May 2001, Tom Lane wrote:
Kovacs Zoltan [EMAIL PROTECTED] writes:
tir= \c - 1060
You are now connected as new user 1060.
tir= select user;
current_user
--
1092
(1 row)
Is it possible that 1060 and 1092 have the same usesysid in pg_shadow?
Hmmm
This may be a reported bug. 7.1beta4.
I use user names mostly as numbers. E.g. 1050, 1060, 1092.
Sometimes I got strange result when I try to reconnect:
tir= \c - 1022
You are now connected as new user 1022.
tir= select user;
current_user
--
1022
(1 row)
(It's OK.)
tir= \c -
On Thu, 8 Mar 2001, Philip Warner wrote:
At 20:48 7/03/01 +, Oliver Elphick wrote:
kovacsz wrote:
You answered that noone experienced anything like this. Here I get this
behaviour with the most simple table as well.
Is there a problem with the lists? I reveived Zoltan's
I have modified formatLiteralString to accept an arg that tells it how to
handle LF TAB. Now, it will encode *everything* except in comments and
procedure bodies.
Thanks, I checked it. So if I want my own output, I must set CONV_ALL=1,
right?
Zoltan
--
Kov\'acs,
Thanks, I checked it. So if I want my own output, I must set CONV_ALL=1,
right?
No. pg_dump now does what you want by default. If not, let me know...
OK, thanks, this behaviour is excellent for me... :-)
--
Kov\'acs, Zolt\'an
[EMAIL
Due to the urgency, I resend my mail about pg_dump output:
In 7.0.2 I got
INSERT INTO foo (field) VALUES ('Hello,\012world!');
In 7.1beta4 I get
INSERT INTO foo (field) VALUES ('Hello,
world!');
I am using these switches: -a, -c, -n, -d or -D.
Is it possible to add a switch to pg_dump to
By the way, I get each sequence twice in pg_dump output... In psql:
CREATE TABLE x (y SERIAL);
Then running pg_dump with switches -xacnOD, I get:
--
-- Selected TOC Entries:
--
DROP SEQUENCE x_y_seq;
DROP SEQUENCE x_y_seq;
--
-- TOC Entry ID 1 (OID 2625010)
--
-- Name: x_y_seq Type: SEQUENCE
Philip, the last element of the chain has caused a big problem for me
changing from 7.0.2 to 7.1beta4: dumping the database out and putting
back.
As you might not know, at my place getting the data from the database is
not a simple pg_dump, but the data come through complex filter programs
(awk
It works! Our production controlling system seems to work with
7.1beta4. In addition, I solved the conversion function problem which was
described in one of my last mails. The problem was I used malloc() instead
of palloc(). Thanks to all of you who developed 7.1 and helped solving the
conversion
On Mon, 29 Jan 2001, Tom Lane wrote:
Kovacs Zoltan [EMAIL PROTECTED] writes:
CREATE TABLE pakolas_cikktetel (
pakolas int4 not null,
cikk int4 not null,
minoseg int4 not null,
sorszam int4 check (sorszam 0),
helyrol int4,
helyre int4,
mennyi numeric
I cannot create a certain table in 7.1beta4. With 7.0.2 there was not any
problem.
--
CREATE TABLE pakolas_cikktetel (
pakolas int4 not null,
cikk int4 not null,
minoseg int4 not null,
sorszam int4 check
My email address has been changed. From now on, please write to
[EMAIL PROTECTED] The "tip" user at the same host no
longer exists. Sorry for the inconvenience if you tried to send a message
to the "tip" user this week.
Have a nice day, :^)
Zoltan
--
Kov\'acs, Zolt\'an
I've got "backend closed" errors --- they seem to be indeterministic.
I am using 7.0.2 but I tried this with 7.1beta3 as well and the error
was similar (but not completely same).
I wrote a char* - char* conversion function. Now I would use textout()
and textin() to make it possible using my
I'm not sure if this is a reported bug or not. SELECT statements with some
aggregates on certain complex views can give terrible results. An example:
CREATE TABLE master (
id int4 not null,
no int4 check (no = 0) default 0,
primary key (id, no),
started date check ((not started
Can I ask about the status of this?
I modified the current ODBC driver for
* referential integrity error reporting,
* SELECT in transactions and
* disabling autocommit.
We are starting to think about organizing additional ODBC testing
Yes, sure. I know that this
27 matches
Mail list logo
