Problem is: to offer such a thing with a straight face, we'd have to
confine ourselves to an Oracle-subset version of SQL. For instance,
lose the ability to distinguish empty-string from NULL.
I wasn't saying we write it - let Oracle do it :D
Chris
---(end of broadcas
1) PostgreSQL to Oracle database conversion utilities released by
Oracle (unlikely given extensible languages in PostgreSQL).
Strangely a pgsql to oracle exporter is a good thing. It'd be a great
feature of PostgreSQL. Imagine how many people would start on
PostgreSQL if they KNEW that one
As Andrew noted, we've already heard plenty of FUD from Oracle. What
we've not seen is a FUD campaign based on serious study of our
weaknesses --- they've only bothered to muster transparent attacks on
"open source DBs" in general. My prediction is that the next step will
be FUD that's really de
If there smart enough to
be buying innobase these days, you can bet that by now they have this stuff
all straightened out.
No, that doesn't seem to follow ... if Oracle are spending their
resources to attack MySQL rather than us, the conclusion would be that
they are clearly still more inform
Please don't make this assumption. PostgreSQL is *very* much on their radar,
and probably represents the biggest long-term threat to their core database
business at the moment. We got a hint of that during the .org bidding, but
for now it is in Oracle's interest not to call attention to PostgreSQL
Argh! That's some sed coolness :)
Chris
Martijn van Oosterhout wrote:
On Fri, Oct 07, 2005 at 04:46:12PM +0800, Christopher Kings-Lynne wrote:
If you have huge plain text dumps, and just want to restore one table
it's usually painful. Attached is a small shell script that can tak
If you have huge plain text dumps, and just want to restore one table
it's usually painful. Attached is a small shell script that can take a
plain text dump and extract a single table's COPY data commands from it.
If people think it's interesting and should be developed, I can pop it
on pgfou
PDF not found?
Chris Travers wrote:
Hi;
I have just posted a MySQL to PostgreSQL migration guide at
http://www.metatrontech.com/wpapers and it is free for pretty much any
use (I do have a somewhat toned-down advertising clause in the copyright
license).
It is a first draft and formatting
I think one of the more difficult areas will be to convert unsigned
fields from mysql into postgres. For smaller sizes it is possible to
convert to postgres by moving one size up and using constraints to
restrict numbers to be positive, and possibly within the mysql range
too. But, the prob
So far, the checklist I can see includes:
* Maintaining conversion scripts
What I think we need is a C program that dumps directly from MySQL into
PostgreSQL sql.
ie. Take the mysqldump source code and just modify its output.
Will inherit the MySQL license though :(
Chris
---
Well, it's not so much that I care about queries with 1000+ relations,
as that this is a good way to stress-test the code and find out where
the performance issues are. There are many thousand lines of code that
can never be performance-sensitive, but to expose the ones that are
it helps to push
Check out EnterprisDB: www.enterprisedb.com
Chris
Edward Peschko wrote:
hey all,
I'm trying to convince some people here to adopt either mysql or postgresql
as a relational database here.. However, we can't start from a clean slate;
we have a very mature oracle database that applications poi
I need a db connection pooling in PHP. As far I know persistent
connections are not the best solution so I'm thinking about using
SQLRelay. Does anyone have any experience using PostgreSQL + PHP +
SQLRelay ? Maybe you know other "connection pooling" solutions for PHP ?
Try pgpool.
Chris
d) Bringing PL/Java into core will force a consistent documentation
and, I imagine, a chapter of it's own in the main docs. I'm happy
to write most of it but English is not my native language. Whatever
I put into print will always benefit from a review.
There is nothing stop'ng a chapter being adde
I find this tiny (9-line) patch useful to help my clients know
when FSM settings may need updating.
Some of the more frequently asked questions here are in regards to FSM
settings. One hint I've seen is to run "vacuum verbose;". At the end
of thousands of lines of INFO and DETAIL messages
update SUBSCRIPTIONTABLE set ACTIVEFLAG='Y' where mobile_num in (select
mobile_num from LOADED_MOBILE_NUMBERS)
Change to:
update SUBSCRIPTIONTABLE set ACTIVEFLAG='Y' where exists (select 1 from
LOADED_MOBILE_NUMBERS lmn where
lmn.mobile_num=SUBSCRIPTIONTABLE.mobile_num);
That should run a lot
> sort_mem = 5
That is way, way too large. Try more like 5000 or lower.
> num_poste | numeric(9,0)| not null
For starters numerics are really, really slow compared to integers. Why
aren't you using an integer for this field since youhave '0' decimal
places.
> sche
But you would have to assign the copyright to them
If someone is going to make money from my code, I prefer it to be me, or
at least that everyone has a chance to do so rather than just one company.
Well, then for the same reason we should write a Perl script that
connects to MySQl and dump
I always ran one of the 2 scripts (can't remember which one) and after that
started checking the dump file, because there were things that didn't get
changed correctly[1].
[1]: I always remember the first conversion I did. I found out that MySQL
accepted dates like 30/2/2000 or 0-0-.
Very o
... on projects.postgresql.org, or similar.They really aren't doing any
good in /contrib.
I've already set up a category "conversion tools" on pgFoundry, and my idea
was one project per target system.
I reckon that by far the best way to do a mysql2pgsql converter is to
just modify mysqldum
I don't think so --- we weren't trying to use it as an actual column
datatype back then.
7.4 has a problem though :-( ... this is one of the "damn I wish we'd
caught that before release" ones, since it can't easily be fixed without
initdb. Reminds me that I need to get to work on making pg_upgrade
> I don't care how but I need to emulate ENUM type, just to convert
> MySQL dumps to PostgreSQL. E.g. ENUM values
> stored in MySQL dump should be restorable in Postgres without any
> conversion.
In MySQL, ENUM is like this:
create table blah (
sex ENUM ('M', 'F')
);
This can be emul
Speaking of MySQL, has anyone looked at www.mysql.org recently?
They have a big news article:
MySQL wins Linux Journal Readers Choice Award again!
For the third Year in a row MySQL won the Readers Choice Award in Linux
Journal. Considering that MySQL earlier this fall won the Linux Magazine
Edi
23 matches
Mail list logo
