Обсуждение: Copy/Paste table(s) functions
Hi, Finally I've made Copy/Paste table(s) operations ! Usage is very simple and intuitive: on right mouse menu for selected connected table or schema select 'Copy table(s)' and than on other connected schema on right mouse menu select 'Paste table(s). Source target server-db might be different but always connected. Best regards, Vladimir Kokovic, DP senior, Belgrade, Serbia
Вложения
Le 31/03/2011 13:31, Vladimir Kokovic a écrit : > Hi, > > Finally I've made Copy/Paste table(s) operations ! > Great. > Usage is very simple and intuitive: > on right mouse menu for selected connected table or schema select > 'Copy table(s)' and than on other connected schema on right mouse menu > select 'Paste table(s). > > Source target server-db might be different but always connected. > I tried it and had different issues. Why should the schema be different? you should better ask the name of the new object. Moreover, if I try to paste on another database, we shouldn't care that the schema is the same. IMNSHO, you should get rid of this check. And if it happens that the table you copy has the same name than another table in the same schema, then ask the user to type the new name. If I copy a table (which is on the public schema) on another schema, I always end up with the message "ERROR: relation "table_name" already exists"). Schema is not added to the table name, so it fails. If I copy from schema s1 to schema s2, it works. I don't like the way you create the sequence, even if Im' not sure there is a better way. The way you check for same database and same host is wrong. This is your check: if (sourceconn->GetDbname() + sourceconn->GetHost() == targetconn->GetDbname() + targetconn->GetHost()) Let's say I have this: * source database: base1 * source host: host1 * dest database: bas * dest host: e1host1 Of course, it is a really stupid example. But with your check, pgAdmin thinks they are the same, even if they aren't. When I finally succeded to copy a table, I found that the browser isn't refreshed. Well, all this is not to discourage you with this tool. I needed some time to agree that it would be a great tool. But it needs more work. Thanks for working on it. Oh, and try to find a way to get rid of the gotos. It hurts my eyes :) -- Guillaume http://www.postgresql.fr http://dalibo.com
Hi, Here's a new version of copy / paste table(s)! I hope this is much better than the previous one.. Best regards, Vladimir Kokovic, DP senior, Belgrade, Serbia
Вложения
Hi,
During copy/paste testing I've found that on 9.1 'COLLATE' should be
omitted from table constraints definitions..Look in my PostgreSQL log:
2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 LOG:
statement: SELECT relname FROM pg_namespace n LEFT JOIN pg_class c ON
n.oid=c.relnamespace AND relkind='r' WHERE nspname='"".""' AND
relname='edi_razmena'
2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 LOG: duration: 7.734 ms
2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 LOG: statement: BEGIN
2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 LOG: duration: 2.135 ms
2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 LOG:
statement: SHOW search_path
2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 LOG: duration: 1.804 ms
2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 ERROR: syntax
error at or near "COLLATE" at character 1232
2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 STATEMENT: SET
search_path=""".""";-- Table: edi_razmena
-- DROP TABLE edi_razmena;
CREATE TABLE edi_razmena
(
godina character varying COLLATE pg_catalog."default" NOT NULL,
razmena_id character varying COLLATE pg_catalog."default" NOT NULL,
char_set character varying COLLATE pg_catalog."default" NOT NULL,
kupac character varying COLLATE pg_catalog."default" NOT NULL,
dobavljac character varying COLLATE pg_catalog."default" NOT NULL,
datum date NOT NULL,
vreme time without time zone NOT NULL,
test character varying COLLATE pg_catalog."default" NOT NULL,
odgovor character varying COLLATE pg_catalog."default" NOT NULL,
ts timestamp without time zone NOT NULL DEFAULT now(),
CONSTRAINT edi_razmena_pkey PRIMARY KEY (godina COLLATE
pg_catalog."default", razmena_id COLLATE pg_catalog."default", kupac
COLLATE pg_catalog."default")
)
WITH (
OIDS=FALSE
);
ALTER TABLE edi_razmena OWNER TO vlada;
GRANT ALL ON TABLE edi_razmena TO vlada;
GRANT ALL ON TABLE edi_razmena TO public;
2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 LOG: statement: ROLLBACK
2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 LOG: duration: 1.383 ms
Best regards,
Vladimir Kokovic, DP senior, Belgrade, Serbia
Le 14/04/2011 10:21, Vladimir Kokovic a écrit : > Hi, > > During copy/paste testing I've found that on 9.1 'COLLATE' should be > omitted from table constraints definitions..Look in my PostgreSQL log: > > 2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 LOG: > statement: SELECT relname FROM pg_namespace n LEFT JOIN pg_class c ON > n.oid=c.relnamespace AND relkind='r' WHERE nspname='"".""' AND > relname='edi_razmena' > 2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 LOG: duration: 7.734 ms > 2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 LOG: statement: BEGIN > 2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 LOG: duration: 2.135 ms > 2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 LOG: > statement: SHOW search_path > 2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 LOG: duration: 1.804 ms > 2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 ERROR: syntax > error at or near "COLLATE" at character 1232 > 2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 STATEMENT: SET > search_path=""".""";-- Table: edi_razmena > > -- DROP TABLE edi_razmena; > > CREATE TABLE edi_razmena > ( > godina character varying COLLATE pg_catalog."default" NOT NULL, > razmena_id character varying COLLATE pg_catalog."default" NOT NULL, > char_set character varying COLLATE pg_catalog."default" NOT NULL, > kupac character varying COLLATE pg_catalog."default" NOT NULL, > dobavljac character varying COLLATE pg_catalog."default" NOT NULL, > datum date NOT NULL, > vreme time without time zone NOT NULL, > test character varying COLLATE pg_catalog."default" NOT NULL, > odgovor character varying COLLATE pg_catalog."default" NOT NULL, > ts timestamp without time zone NOT NULL DEFAULT now(), > CONSTRAINT edi_razmena_pkey PRIMARY KEY (godina COLLATE > pg_catalog."default", razmena_id COLLATE pg_catalog."default", kupac > COLLATE pg_catalog."default") > ) > WITH ( > OIDS=FALSE > ); > ALTER TABLE edi_razmena OWNER TO vlada; > GRANT ALL ON TABLE edi_razmena TO vlada; > GRANT ALL ON TABLE edi_razmena TO public; > > 2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 LOG: statement: ROLLBACK > 2011-04-14 10:04:28 CEST asoft 127.0.0.1(41254) 5357 0 LOG: duration: 1.383 ms > I don't see how you can have that issue. When I add a primary key (to a new table or to an existing table), I don't have a COLLATE clause. -- Guillaume http://www.postgresql.fr http://dalibo.com
Hi, Here is patch for TABLE PRIMARY KEY CONSTRAINT on PostgreSQL 9.1 Best regards, Vladimir Kokovic, DP senior, Belgrade, Serbia
Вложения
Le 18/04/2011 05:27, Vladimir Kokovic a écrit : > [...] > Here is patch for TABLE PRIMARY KEY CONSTRAINT on PostgreSQL 9.1 > That doesn't answer my question on how to reproduce it. Or it doesn't have anything to me with my previous answer, but in this case, it would help to have some kind of an explanation on the intent of the patch. -- Guillaume http://www.postgresql.fr http://dalibo.com
Le 18/04/2011 09:15, Vladimir Kokovic a écrit : > Hi, > > Problem is in the text which is returned with pgTable.getSql ! > Without patch primary key contains word 'COLLATE' which PostgreSQL > does not expect. > Yeah, you already said that. I didn't reproduce it. And your patch doesn't forbid it. It makes sure that we don't have the COLLATE clause for the default collation. Anyways, what I need is a way to reproduce the issue. What are the exact steps I need to follow to reproduce it? Thanks. Oh, and please, don't forget to CC the list. -- Guillaume http://www.postgresql.fr http://dalibo.com
Hi, 1.Select server 2.Select database 3.select schema 4.select table with primary key which contains character varying.field 5.look in SQL pane line for the primary key definition If your selected server is PostgreSQL 9.1, primary key looks like: CONSTRAINT edi_razmena_pkey PRIMARY KEY (godina COLLATE pg_catalog."default", razmena_id COLLATE pg_catalog."default", kupac COLLATE pg_catalog."default") 6.If you apply patch, primary key looks like: CONSTRAINT edi_razmena_pkey PRIMARY KEY (godina, razmena_id, kupac) Best regards, Vladimir Kokovic, DP senior, Belgrade, Serbia
Le 18/04/2011 11:04, Vladimir Kokovic a écrit : > Hi, > > 1.Select server > 2.Select database > 3.select schema > 4.select table with primary key which contains character varying.field > 5.look in SQL pane line for the primary key definition > If your selected server is PostgreSQL 9.1, primary key looks like: > CONSTRAINT edi_razmena_pkey PRIMARY KEY (godina COLLATE > pg_catalog."default", razmena_id COLLATE pg_catalog."default", kupac > COLLATE pg_catalog."default") > 6.If you apply patch, primary key looks like: > CONSTRAINT edi_razmena_pkey PRIMARY KEY (godina, razmena_id, kupac) > OK, I reproduce it now. The patch I wrote fixed also the index in the browser. Thanks for your report. -- Guillaume http://www.postgresql.fr http://dalibo.com