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 o
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 123
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 o
> > 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,
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 wh
> 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 behavio
> 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
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
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)
>
&
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 - 1
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 reveive
> >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 PR
> 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, Z
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 Ow
On Mon, 12 Feb 2001, Peter Eisentraut wrote:
> Kovacs Zoltan writes:
>
> > 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!');
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 mak
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 s
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),
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 (
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 conv
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'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 i
> 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
28 matches
Mail list logo
