ViSolve DB Team wrote:
> Hi,
>
>> From MySQL 4.1, there is a support for mysqldump --compatible option.
> There is a safe/cool dump for your table:
> Try lik:
> shell > mysqldump -u dev -p visolvetestdb credits
> --compatible=postgresql > /home/test/ps.sql
>
> And also,
> By default tables are d
Jim C. wrote:
OK, I've another question. This one is about the INSERT command.
When I uncomment some of these statements I get an error in regards to a
comma. What I'm afraid of is that perhaps there is a compatibility
issue such that an INSERT command on Postgres can't take as many records
as
On 2/5/07, Jim C. wrote:
When I uncomment some of these statements I get an error in regards to a
comma. What I'm afraid of is that perhaps there is a compatibility
issue such that an INSERT command on Postgres can't take as many records
as MySQL.
What version are you running?
Jochem
--
MyS
On 2/5/07, Jim C. wrote:
CREATE TABLE "credits" (
"person" integer NOT NULL default '0',
"chanid" int NOT NULL default '0',
"starttime" timestamp NOT NULL default '1970-01-01 00:00:00+00',
"role" VARCHAR NOT NULL,
CONSTRAINT role_check CHECK "role" IN
('actor','director','producer','ex
Chris White wrote:
> Jim C. wrote:
>>> CREATE TABLE "credits" (
>>> "person" integer NOT NULL default '0',
>>> "chanid" int NOT NULL default '0',
>>> "starttime" timestamp NOT NULL default '1970-01-01 00:00:00+00',
>>> "role" VARCHAR NOT NULL,
>>> CONSTRAINT role_check CHECK "role" IN
>>
Jim C. wrote:
CREATE TABLE "credits" (
"person" integer NOT NULL default '0',
"chanid" int NOT NULL default '0',
"starttime" timestamp NOT NULL default '1970-01-01 00:00:00+00',
"role" VARCHAR NOT NULL,
CONSTRAINT role_check CHECK "role" IN
('actor','director','producer','executive_pro
OK, I've another question. This one is about the INSERT command.
When I uncomment some of these statements I get an error in regards to a
comma. What I'm afraid of is that perhaps there is a compatibility
issue such that an INSERT command on Postgres can't take as many records
as MySQL. Seems to
> CREATE TABLE "credits" (
> "person" integer NOT NULL default '0',
> "chanid" int NOT NULL default '0',
> "starttime" timestamp NOT NULL default '1970-01-01 00:00:00+00',
> "role" VARCHAR NOT NULL,
> CONSTRAINT role_check CHECK "role" IN
> ('actor','director','producer','executive_produ
> It looks more like the person that designed the schema has payed very
> little attention to the SQL standard. You can not blame anyone but the
> designer for naming a field 'role' (which is a keyword in the SQL
> standard) or using a non-standard set field type instead of a proper
> lookup table.
> It looks more like the person that designed the schema has payed very
> little attention to the SQL standard. You can not blame anyone but the
> designer for naming a field 'role' (which is a keyword in the SQL
> standard) or using a non-standard set field type instead of a proper
> lookup table.
On 2/2/07, Jim C. <[EMAIL PROTECTED]> wrote:
I'm having to move some data from MySQL to Postgres. I used mysqldump
--compatible=postgresql, but the compatibility is extremely lacking.
It looks more like the person that designed the schema has payed very
little attention to the S
gt;
To:
Sent: Friday, February 02, 2007 10:31 PM
Subject: MySQL to Postgres
I'm having to move some data from MySQL to Postgres. I used mysqldump
--compatible=postgresql, but the compatibility is extremely lacking. I'm
actually rather shocked that there doesn't seem to be a common open
I'm having to move some data from MySQL to Postgres. I used mysqldump
--compatible=postgresql, but the compatibility is extremely lacking. I'm
actually rather shocked that there doesn't seem to be a common open
standard (XML?) in use for this sort of thing.
Anyway, I'm ha
13 matches
Mail list logo
