Re: [GENERAL] moving from MySQL to pgsql
On 2012-10-13, Merlin Moncure mmonc...@gmail.com wrote: On Sat, Oct 13, 2012 at 3:22 AM, Jasen Betts ja...@xnet.co.nz wrote: On 2012-10-11, Vineet Deodhar vineet.deod...@gmail.com wrote: To give an example, I have tables for storing master records (year master, security master, etc.) for which pkid TINYINT is just sufficient. These pkid's are used as fk constraints in tables for storing business transactions. The no. of rows in business transactions tables is in millions. Here, I NEED to worry about the storage space occupied by the pkid fields. with disk at about 50c/Gigabyte why is it you need to worry? see upthread: OP is running off a USB stick. If he's running MyISAM, the postgres database is going to be larger and there is going to be a lot more writing than he's used to. So, $5/gigabyte, and shorter life than disk, I can see how that could start to hurt if you need to deploy a thousand. -- ⚂⚃ 100% natural -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On 2012-10-10, Vineet Deodhar vineet.deod...@gmail.com wrote: --f46d040714c5d7a08c04cbb08256 Content-Type: text/plain; charset=UTF-8 Hi ! At present, I am using MySQL as backend for my work. Because of the licensing implications, I am considering to shift from MySQL to pgsql. Typically, my apps are multi-user, web based or LAN based. 1) Read over the internet that --- Postgres is not threaded, but every connection gets it's own process. The OS will distribute the processes across the processors. Basically a single connection will not be any faster with SMP, but multiple connections will be. MySQL is multi-threaded server so it can use many processors. A separate thread is created for each connection. source: http://dcdbappl1.cern.ch:8080/dcdb/archive/ttraczyk/db_compare/db_compare.html#Comparison+of+Oracle%2C+MySQL+and+Postgres+DBMS In what way it might affect my app performance? It's going to hurt a bit if creating processes is expensive and you need many. 2) I run MySQL from a USB stick. There is no installation required (on WinXP.). (not tried on Ubuntu) Is it the same for pgsql? It's probably possible, but usb flash gets you all the disadvantages of SSD with no benefits (except portability), you'd probably have to reformat the usb to NTFS - windows FAT doesn't support postgres. And you'd also need to do a custom install. 3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data type or something else) Probably what properties of tinyint do you need? -- ⚂⚃ 100% natural -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On 2012-10-11, Vineet Deodhar vineet.deod...@gmail.com wrote: To give an example, I have tables for storing master records (year master, security master, etc.) for which pkid TINYINT is just sufficient. These pkid's are used as fk constraints in tables for storing business transactions. The no. of rows in business transactions tables is in millions. Here, I NEED to worry about the storage space occupied by the pkid fields. with disk at about 50c/Gigabyte why is it you need to worry? -- ⚂⚃ 100% natural -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On Sat, Oct 13, 2012 at 3:22 AM, Jasen Betts ja...@xnet.co.nz wrote: On 2012-10-11, Vineet Deodhar vineet.deod...@gmail.com wrote: To give an example, I have tables for storing master records (year master, security master, etc.) for which pkid TINYINT is just sufficient. These pkid's are used as fk constraints in tables for storing business transactions. The no. of rows in business transactions tables is in millions. Here, I NEED to worry about the storage space occupied by the pkid fields. with disk at about 50c/Gigabyte why is it you need to worry? see upthread: OP is running off a USB stick. If he's running MyISAM, the postgres database is going to be larger and there is going to be a lot more writing than he's used to. merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On Thu, Oct 11, 2012 at 5:26 AM, Ondrej Ivanič ondrej.iva...@gmail.comwrote: Hi, On 10 October 2012 19:47, Vineet Deodhar vineet.deod...@gmail.com wrote: 3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data type or something else) What do you exactly mean? Do you care about storage requirements or constraints? The smallest numeric type in postgres is smallint: range is +/- 32K and you need two bytes. You can use check constraint to restrict the range (postgres doesn't have signed / unsigned types): create table T ( tint_signed smallint check ( tint_signed = -128 and tint_signed = 127 ), tint_unsigned smallint check ( tint_unsigned = 0 and tint_unsigned = 255 ) ) Yes. Considering the storage requirements , I am looking for TINYINT kind of data type. if you care about storage then char (yes, with quotes) might be the right type for you. -- Ondrej Ivanic (ondrej.iva...@gmail.com) (http://www.linkedin.com/in/ondrejivanic) If I use char for numeric field, would it be possible to do numeric operations comparisons such as max(tint_unsigned) ? --- Vineet
Re: [GENERAL] moving from MySQL to pgsql
Le 10/10/2012 10:47, Vineet Deodhar a écrit : Hi ! 3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data type or something else) Another way, and a good practice toot is to use SQL DOMAINs wich is a part of the ISO SQL since 1992 that MySQL don't have... CREATE DOMAIN TINYINT AS SMALLINT CHECK (VALUE BETWEEN 0 AND 255) Most part of the modelling tools are able to use DOMAINs in their modelling process, like PowerDesigner, Mega, ERwin, Rational... A + -- Frédéric BROUARD - expert SGBDR et SQL - MVP SQL Server - 06 11 86 40 66 Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Enseignant Arts Métiers PACA, ISEN Toulon et CESI/EXIA Aix en Provence Audit, conseil, expertise, formation, modélisation, tuning, optimisation *** http://www.sqlspot.com * -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On 10/11/2012 02:07 PM, Vineet Deodhar wrote: On Thu, Oct 11, 2012 at 5:26 AM, Ondrej Ivanič ondrej.iva...@gmail.com mailto:ondrej.iva...@gmail.com wrote: Hi, On 10 October 2012 19:47, Vineet Deodhar vineet.deod...@gmail.com mailto:vineet.deod...@gmail.com wrote: 3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data type or something else) What do you exactly mean? Do you care about storage requirements or constraints? The smallest numeric type in postgres is smallint: range is +/- 32K and you need two bytes. You can use check constraint to restrict the range (postgres doesn't have signed / unsigned types): create table T ( tint_signed smallint check ( tint_signed = -128 and tint_signed = 127 ), tint_unsigned smallint check ( tint_unsigned = 0 and tint_unsigned = 255 ) ) Yes. Considering the storage requirements , I am looking for TINYINT kind of data type. The storage difference between `SMALLINT` and a `TINYINT` would be ... tiny, given the space taken up by tuple headers, etc. As it is, a row containing four SMALLINT columns is 32 bytes, vs 40 bytes for INTEGER columns or 28 for BOOLEAN. regress=# SELECT pg_column_size( (BOOLEAN 't', BOOLEAN 't', BOOLEAN 'f', BOOLEAN 'f') ); pg_column_size 28 (1 row) regress=# SELECT pg_column_size( (SMALLINT '2', SMALLINT '3', SMALLINT '4', SMALLINT '5') ); pg_column_size 32 (1 row) regress=# SELECT pg_column_size( (INTEGER '2', INTEGER '3', INTEGER '4', INTEGER '5') ); pg_column_size 40 (1 row) The difference between SMALLINT and BOOLEAN (or TINYINT if Pg supported it) is 1 byte per column. If you had 30 smallint columns and quite a few million rows it might start making a difference, but it's *really* not worth obsessing about. Unless you have high-column-count tables that contain nothing but lots of integers of range 0-255 there's no point caring. -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On Thu, Oct 11, 2012 at 1:12 PM, Craig Ringer ring...@ringerc.id.au wrote: The difference between SMALLINT and BOOLEAN (or TINYINT if Pg supported it) is 1 byte per column. If you had 30 smallint columns and quite a few million rows it might start making a difference, but it's *really* not worth obsessing about. Unless you have high-column-count tables that contain nothing but lots of integers of range 0-255 there's no point caring. -- Craig Ringer To give an example, I have tables for storing master records (year master, security master, etc.) for which pkid TINYINT is just sufficient. These pkid's are used as fk constraints in tables for storing business transactions. The no. of rows in business transactions tables is in millions. Here, I NEED to worry about the storage space occupied by the pkid fields. -- Vineet
Re: [GENERAL] moving from MySQL to pgsql
On Thu, Oct 11, 2012 at 3:04 PM, Craig Ringer ring...@ringerc.id.au wrote: AFAIK in most situations alignment requirements will mean you won't gain any space in those situations anyway. I would be truly amazed if you saw more than something like a 1% difference in size due to this; it'll be *massively* outweighed by all the other differences. You're optimising prematurely. See if it's a problem in practice, and if it is look into using a custom data type (warning: lots of work) or some other approach. -- Craig Ringer OK. As per your advise, let me put smallint into practice and analyze the storage requirement. Thanks a lot. -- Vineet -- Best regards, Vineet Deodhar 0 9270012422( Sales) 0 9420 6767 41 / 0 844 6268 488 (Service) 0233-2300136 (Back-Office)
Re: [GENERAL] moving from MySQL to pgsql
Thanks all for your replies. This is my first experience with postgres mailing list. Hats Off to the active community of pgsql. This has definitely raised my confidence level with postgres. --- Vineet
Re: [GENERAL] moving from MySQL to pgsql
On 10/11/2012 05:07 PM, Vineet Deodhar wrote: On Thu, Oct 11, 2012 at 1:12 PM, Craig Ringer ring...@ringerc.id.au mailto:ring...@ringerc.id.au wrote: The difference between SMALLINT and BOOLEAN (or TINYINT if Pg supported it) is 1 byte per column. If you had 30 smallint columns and quite a few million rows it might start making a difference, but it's *really* not worth obsessing about. Unless you have high-column-count tables that contain nothing but lots of integers of range 0-255 there's no point caring. -- Craig Ringer To give an example, I have tables for storing master records (year master, security master, etc.) for which pkid TINYINT is just sufficient. These pkid's are used as fk constraints in tables for storing business transactions. The no. of rows in business transactions tables is in millions. Here, I NEED to worry about the storage space occupied by the pkid fields. AFAIK in most situations alignment requirements will mean you won't gain any space in those situations anyway. I would be truly amazed if you saw more than something like a 1% difference in size due to this; it'll be *massively* outweighed by all the other differences. You're optimising prematurely. See if it's a problem in practice, and if it is look into using a custom data type (warning: lots of work) or some other approach. -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On Thu, Oct 11, 2012 at 4:44 AM, Vineet Deodhar vineet.deod...@gmail.com wrote: Thanks all for your replies. This is my first experience with postgres mailing list. Hats Off to the active community of pgsql. This has definitely raised my confidence level with postgres. thanks. we like emails that start off 'moving to pgsql from xxx'. If you want a 24x7 crack dedicated support team, claim to be frustrated with postgres and evaluating migration to SQL Server. :-). merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On 12/10/12 04:39, Merlin Moncure wrote: On Thu, Oct 11, 2012 at 4:44 AM, Vineet Deodhar vineet.deod...@gmail.com wrote: Thanks all for your replies. This is my first experience with postgres mailing list. Hats Off to the active community of pgsql. This has definitely raised my confidence level with postgres. thanks. we like emails that start off 'moving to pgsql from xxx'. If you want a 24x7 crack dedicated support team, claim to be frustrated with postgres and evaluating migration to SQL Server. :-). merlin Surely we should le people migrate to SQL Server grom postgres - as it will be its own punishment? :-) Cheers, Gavin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On Thu, Oct 11, 2012 at 9:38 AM, Gavin Flower gavinflo...@archidevsys.co.nz wrote: On 12/10/12 04:39, Merlin Moncure wrote: On Thu, Oct 11, 2012 at 4:44 AM, Vineet Deodhar vineet.deod...@gmail.com wrote: Thanks all for your replies. This is my first experience with postgres mailing list. Hats Off to the active community of pgsql. This has definitely raised my confidence level with postgres. thanks. we like emails that start off 'moving to pgsql from xxx'. If you want a 24x7 crack dedicated support team, claim to be frustrated with postgres and evaluating migration to SQL Server. :-). merlin Surely we should le people migrate to SQL Server grom postgres - as it will be its own punishment? :-) I'll take SQL Server over Oracle any day of the week though..
Re: [GENERAL] moving from MySQL to pgsql
On 10/11/12 2:07 AM, Vineet Deodhar wrote: To give an example, I have tables for storing master records (year master, security master, etc.) for which pkid TINYINT is just sufficient. These pkid's are used as fk constraints in tables for storing business transactions. The no. of rows in business transactions tables is in millions. Here, I NEED to worry about the storage space occupied by the pkid fields. IMHO, its not significant to save a byte per field unless there's 30 or 100 of these fields in a single row. -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On Wed, Oct 10, 2012 at 1:47 AM, Vineet Deodhar vineet.deod...@gmail.comwrote: Hi ! At present, I am using MySQL as backend for my work. Because of the licensing implications, I am considering to shift from MySQL to pgsql. Typically, my apps are multi-user, web based or LAN based. 1) Read over the internet that --- Postgres is not threaded, but every connection gets it's own process. The OS will distribute the processes across the processors. Basically a single connection will not be any faster with SMP, but multiple connections will be. MySQL is multi-threaded server so it can use many processors. A separate thread is created for each connection. source: http://dcdbappl1.cern.ch:8080/dcdb/archive/ttraczyk/db_compare/db_compare.html#Comparison+of+Oracle%2C+MySQL+and+Postgres+DBMS In what way it might affect my app performance? Not much. MySQL doesn't support intraquery parallelism to my knowledge. You will get extra robustness due to process isolation however. There might be some slight costs due to shared memory management overhead but these are probably insignificant compared to other factors. PostgreSQL has an excellent optimizer and the on-disk layout is completely different. This will dwarf any changes due to threads vs queries. However be prepared to rethink your indexing strategies. 2) I run MySQL from a USB stick. There is no installation required (on WinXP.). (not tried on Ubuntu) Is it the same for pgsql? You would want a user account created because PostgreSQL won't run as an administrator but otherwise, yes. 3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data type or something else) I would use smallint (2 byte int), but if you have to char with quotes should give you a one byte field. I don't know about utf8 tules on it though. Best Wishes, Chris Travers
Re: [GENERAL] moving from MySQL to pgsql
On 10/10/2012 10:47 AM, Vineet Deodhar wrote: Hi ! At present, I am using MySQL as backend for my work. Because of the licensing implications, I am considering to shift from MySQL to pgsql. Typically, my apps are multi-user, web based or LAN based. 1) Read over the internet that --- Postgres is not threaded, but every connection gets it's own process. The OS will distribute the processes across the processors. Basically a single connection will not be any faster with SMP, but multiple connections will be. MySQL is multi-threaded server so it can use many processors. A separate thread is created for each connection. source: http://dcdbappl1.cern.ch:8080/dcdb/archive/ttraczyk/db_compare/db_compare.html#Comparison+of+Oracle%2C+MySQL+and+Postgres+DBMS In what way it might affect my app performance? Performance will not be affected negatively. MySQL only has one thread per connection, so a single query will never use multiple threads (scary concept to think about). 2) I run MySQL from a USB stick. There is no installation required (on WinXP.). (not tried on Ubuntu) Is it the same for pgsql? To use postgres on a USB stick, see http://www.postgresonline.com/journal/archives/172-Starting-PostgreSQL-in-windows-without-install.html 3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data type or something else) You can either use bool or smallint with a constraint. Sim
Re: [GENERAL] moving from MySQL to pgsql
On Wed, Oct 10, 2012 at 2:38 PM, Chris Travers chris.trav...@gmail.comwrote: On Wed, Oct 10, 2012 at 1:47 AM, Vineet Deodhar vineet.deod...@gmail.comwrote: PostgreSQL has an excellent optimizer and the on-disk layout is completely different. This will dwarf any changes due to threads vs queries. However be prepared to rethink your indexing strategies. Best Wishes, Chris Travers Thanks Chris. I didn't understand by what do you mean by be prepared to rethink your indexing strategies. In MySQL, I have created indexes, Unique indexes, complex or multi-field indexes, etc. In what way should I re-consider the indexing? Thanks, Vineet
Re: [GENERAL] moving from MySQL to pgsql
On Wed, Oct 10, 2012 at 3:47 AM, Vineet Deodhar vineet.deod...@gmail.com wrote: Hi ! At present, I am using MySQL as backend for my work. Because of the licensing implications, I am considering to shift from MySQL to pgsql. Typically, my apps are multi-user, web based or LAN based. 1) Read over the internet that --- Postgres is not threaded, but every connection gets it's own process. The OS will distribute the processes across the processors. Basically a single connection will not be any faster with SMP, but multiple connections will be. MySQL is multi-threaded server so it can use many processors. A separate thread is created for each connection. source: PostgreSQL is multi-threaded in that it has multiple execution threads. The only difference is that each thread has its own process where in mysql every thread runs in the same process. Each approach has various pros and cons that ultimately don't matter most applications. In what way it might affect my app performance? Basically, it doesn't -- at least not very much. There are many other things that are going to make a much bigger difference. 2) I run MySQL from a USB stick. There is no installation required (on WinXP.). (not tried on Ubuntu) Is it the same for pgsql? Not sure what you mean there. Mysql has a windows installer, as does postgres. It's possible to bootstrap postgres without an installer if you know what you're doing, but generally silent mode install is the way to go. You've omitted some very important details, like the specific security model of the windows environments you'll install to. 3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data type or something else) You have a couple of options: Postgresql explicitly-double-quoted char, which is a byte. Another options is to use smallint + check constraints. merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
Hi, On 10 October 2012 19:47, Vineet Deodhar vineet.deod...@gmail.com wrote: 3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data type or something else) What do you exactly mean? Do you care about storage requirements or constraints? The smallest numeric type in postgres is smallint: range is +/- 32K and you need two bytes. You can use check constraint to restrict the range (postgres doesn't have signed / unsigned types): create table T ( tint_signed smallint check ( tint_signed = -128 and tint_signed = 127 ), tint_unsigned smallint check ( tint_unsigned = 0 and tint_unsigned = 255 ) ) if you care about storage then char (yes, with quotes) might be the right type for you. -- Ondrej Ivanic (ondrej.iva...@gmail.com) (http://www.linkedin.com/in/ondrejivanic) -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
I noticed something here that none of the other replies addressed. Vineet Deodhar wrote: 3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data type or something else) The answer to your question depends on what you were using the TINYINT for. For example, many people use TINYINT in MySQL to store BOOLEAN (true/false) data because MySQL doesn't have a real BOOLEAN type; MySQL has the BOOLEAN keyword, but if you choose it then what you actually get is a TINYINT. And so, if you are actually using the field just for true/false or 1/0 values, then Postgres' BOOLEAN type (which is not a number) is the best thing for you to use. If you were storing actual numbers outside that range, then use SMALLINT or something like that. Any reverse engineering of the MySQL schema will never know you used the BOOLEAN keyword and just say you have a TINYINT, so you may have to study your schema and its uses more to know what kind of data/type you actually have. -- Darren Duncan -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On 10/10/2012 02:18 AM, Sim Zacks wrote: 2) I run MySQL from a USB stick. There is no installation required (on WinXP.). (not tried on Ubuntu) Is it the same for pgsql? To use postgres on a USB stick, see http://www.postgresonline.com/journal/archives/172-Starting-PostgreSQL-in-windows-without-install.html 3) Can I simulate MySQL's TINYINT data-type (using maybe the custom data type or something else) You can either use bool or smallint with a constraint. Or he could create a custom type easily enough. JD Sim -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development High Availability, Oracle Conversion, Postgres-XC @cmdpromptinc - 509-416-6579 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] moving from MySQL to pgsql
On 10/10/2012 04:47 PM, Vineet Deodhar wrote: 2) I run MySQL from a USB stick. There is no installation required (on WinXP.). (not tried on Ubuntu) Is it the same for pgsql? On Windows PostgreSQL is usually installed as a system service with its own user account (pre-9.2) or running in the network service account (9.2+). This isn't strictly required, though. You can keep the .zip binary releases on a USB key and use pg_ctl to start/stop them from your own scripts. If you're bundling Pg in your application this may be the best choice. See: http://www.enterprisedb.com/products-services-training/pgbindownload You *really* shouldn't keep the database its self on a USB key. Performance is likely to be terrible, and many USB keys have quite short write lifetimes so a database on a USB key can wear some of them out in a real hurry. Think about your backup process too. With PostgreSQL you have a couple of options, including log archiving, periodic dumps, and warm standby. Please read the backup chapter of the manual in detail. -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Moving from Mysql
On Sat, May 22, 2010 at 11:06:02PM -0400, Stephen Frost wrote: * Luis Daniel Lucio Quiroz (luis.daniel.lu...@gmail.com) wrote: 1. whar are equivalent for these commands: in mysql: mysqldump mydata_base_name pg_dump (pg_restore to restore from the dump, if you use a non-SQL format for it, which can give you the ability to do a parallel-restore) The way to call pg_dump so it goes to the most flexible format in pg_dump -Fc. You can find out more about this format in the man page, if you're using a unix-like system, or in the on-line docs: http://www.postgresql.org/docs/current/static/app-pgdump.html mysql mydata_base_name script.sql psql With the output of pg_dump -Fc, you'll be using pg_restore, which is more complex, but much more flexible. http://www.postgresql.org/docs/current/static/app-pgrestore.html 2. any link to read about how to admin pgsql with mysql backgraounds, The PG documentation is really quite good: http://www.postgresql.org/docs/8.4/ Here are a few more specific ones, some of which may apply to your situation: http://sql-info.de/mysql/gotchas.html http://www.raditha.com/mysql/mysql2pgsql.php http://www.in-nomine.org/~asmodai/mysql-to-pgsql.html http://blog.gtuhl.com/2010/04/15/not-a-fan-of-mysql/ http://pgfoundry.org/projects/mysql2pgsql/ http://search.cpan.org/search?query=SQL%3A%3ATranslatormode=all http://www.metatrontech.com/wpapers/mysql2postgresql.pdf http://www.data-conversions.net/products.php?prod_num=5dest=MENUID=200 http://pgfoundry.org/projects/mysqlcompat 3. how users are managed in pgsql, i need to create a specifiq username for db, but how? PG Roles (users and groups) are managed on a per-cluster level. There isn't a really good way to do them at a per-database level today. A cluster in PG is a full PG instance and a single cluster contains multiple databases. You can manage which databases users are allowed to connect to though, check out the GRANT command. Also check out host-based authentication, which you control with an external file called pg_hba.conf: http://www.postgresql.org/docs/current/static/client-authentication.html Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Moving from Mysql
Hi, Well, i'm moving some databases from Mysql to Pgsql, but i'm having some admin doubts, i wondering 3 things: 1. whar are equivalent for these commands: in mysql: mysqldump mydata_base_name mysql mydata_base_name script.sql 2. any link to read about how to admin pgsql with mysql backgraounds, 3. how users are managed in pgsql, i need to create a specifiq username for db, but how? TIA LD -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Moving from Mysql
* Luis Daniel Lucio Quiroz (luis.daniel.lu...@gmail.com) wrote: 1. whar are equivalent for these commands: in mysql: mysqldump mydata_base_name pg_dump (pg_restore to restore from the dump, if you use a non-SQL format for it, which can give you the ability to do a parallel-restore) mysql mydata_base_name script.sql psql 2. any link to read about how to admin pgsql with mysql backgraounds, The PG documentation is really quite good: http://www.postgresql.org/docs/8.4/ 3. how users are managed in pgsql, i need to create a specifiq username for db, but how? PG Roles (users and groups) are managed on a per-cluster level. There isn't a really good way to do them at a per-database level today. A cluster in PG is a full PG instance and a single cluster contains multiple databases. You can manage which databases users are allowed to connect to though, check out the GRANT command. Thanks, Stephen signature.asc Description: Digital signature
Re: [GENERAL] moving from mysql to postgree
Thanks every body, today i've created my first table with postgresql, what a mass with \d table and sequancial vs auto_increment data type in create... anyway, i will become an expert soon ;-) thanks again pau 2007/11/16, Merlin Moncure [EMAIL PROTECTED]: On Nov 15, 2007 10:44 AM, Pau Marc Munoz Torres [EMAIL PROTECTED] wrote: I'm moving from mysql to postgresql just now i I'm a bit lost, could anyone tell me some place with a comparative between postdresql and mysql commands, i think than mostly is the same think but, any way, do anything change ? IMO, he biggest differences between mysql and postgresql for beginners are: * database authentication (pg_hba.conf and user set up) * create/alter table syntax * dealing with timestamps/default expressions * update and delete statements that deal with more than one table postgresql has a _much_ better command shell than mysql. It has tab-completions for commands as well as database objects and has syntax help for all commands. This is an absolutely essential help to the beginner. (some of the gui tools, like pgadmin, have this as well but i use the shell almost exclusively). \h command in the shell will give you help for the command and \d table well 'describe' the table good luck!! merlin -- Pau Marc Muñoz Torres Laboratori de Biologia Computacional Institut de Biotecnologia i Biomedicina Vicent Villar Universitat Autonoma de Barcelona E-08193 Bellaterra (Barcelona) telèfon: 93 5812807 Email : [EMAIL PROTECTED]
Re: [GENERAL] moving from mysql to postgree
On Nov 15, 2007 10:44 AM, Pau Marc Munoz Torres [EMAIL PROTECTED] wrote: I'm moving from mysql to postgresql just now i I'm a bit lost, could anyone tell me some place with a comparative between postdresql and mysql commands, i think than mostly is the same think but, any way, do anything change ? IMO, he biggest differences between mysql and postgresql for beginners are: * database authentication (pg_hba.conf and user set up) * create/alter table syntax * dealing with timestamps/default expressions * update and delete statements that deal with more than one table postgresql has a _much_ better command shell than mysql. It has tab-completions for commands as well as database objects and has syntax help for all commands. This is an absolutely essential help to the beginner. (some of the gui tools, like pgadmin, have this as well but i use the shell almost exclusively). \h command in the shell will give you help for the command and \d table well 'describe' the table good luck!! merlin ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[GENERAL] moving from mysql to postgree
Hi I'm moving from mysql to postgresql just now i I'm a bit lost, could anyone tell me some place with a comparative between postdresql and mysql commands, i think than mostly is the same think but, any way, do anything change ? pau -- Pau Marc Muñoz Torres Laboratori de Biologia Computacional Institut de Biotecnologia i Biomedicina Vicent Villar Universitat Autonoma de Barcelona E-08193 Bellaterra (Barcelona) telèfon: 93 5812807 Email : [EMAIL PROTECTED]
Re: [GENERAL] moving from mysql to postgree
Pau Marc Munoz Torres wrote: Hi I'm moving from mysql to postgresql just now i I'm a bit lost, could anyone tell me some place with a comparative between postdresql and mysql commands, i think than mostly is the same think but, any way, do anything change ? pau -- Hi, You should check out Lightning Admin. We have a version for both that have the same look and feel and could make the transition easier. You can also ask questions at our forums: http://www.amsoftwaredesign.com/smf regarding moving from MySQL to PostgreSQL. Tony Caduto http://www.amsoftwaredesign.com Home of Lightning Admin for PostgreSQL and MySQL Both versions for 24.99 (limited time only). ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] moving from mysql to postgree
On Thu, Nov 15, 2007 at 04:44:33PM +0100, Pau Marc Munoz Torres wrote: I'm moving from mysql to postgresql just now i I'm a bit lost, could anyone tell me some place with a comparative between postdresql and mysql commands, i think than mostly is the same think but, any way, do anything change ? You can probably get a reasonable sense of the differences by looking at section VI of the manual -- it's basically the man page version of every SQL statement. That said, I _very strongly_ encourage you to read the whole manual, at least once. It's admittedly a bit of a slog, but there are a number of deep conceptual differences between PostgreSQL and MySQL that will possibly bite you unless you are prepared for them. Better to be prepared than to be up at 3 AM :) If you are not familiar with MySQL's strict mode, then the above is even more important. If you _are_ familiar with strict mode, then think of PostgreSQL as strict mode done properly, and which you can't shut off. There are also some MySQL-to-PostgreSQL comparison sites around that you'll want to read. A -- Andrew Sullivan Old sigs will return after re-constitution of blue smoke ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] Moving from MySQL to PostgreSQL with Ruby on Rails.
On Nov 17, 2005, at 4:44 PM, Robby Russell wrote: Sort of a meta-approach for Rails-based scaffolding generator. Not required, but it'll speed up the process and limit the number of chars that you can stick into a text field opposed to a text area. Yet again you see RoR compensating for lack of data integrity checking in the DB of choice... :-) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[GENERAL] Moving from MySQL to PostgreSQL with Ruby on Rails.
Hi, I'm just new to the PostgreSQL world. I've been using MySQL but I want to develop a Ruby on Rails application that can be installed on either MySQL or PostgreSQL. I don't know how much the DDL dialects vary between them. At the moment I am interested in the options on a table like UTF-8. In MySQL I write CREATE TABLE product ( id INT NOT NULL AUTOINCREMENT, name VARCHAR(255) NOT NULL DEFAULT '', PRIMARY KEY (id) ) DEFAULT CHARSET=UTF-8; Will this definition work in the PostgreSQL world? Is there a web page for people with MySQL exerience moving to PostgreSQL? Part of the issue is the way Ruby on Rails migration class enables me to add options to Rails' own abstraced DDL just like I have done in the above example. Other ways of adding options might be tricky. Thanks, Peter
Re: [GENERAL] Moving from MySQL to PostgreSQL with Ruby on Rails.
On Thu, 2005-11-17 at 08:48 -0800, Peter Michaux wrote: Hi, I'm just new to the PostgreSQL world. I've been using MySQL but I want to develop a Ruby on Rails application that can be installed on either MySQL or PostgreSQL. I don't know how much the DDL dialects vary between them. At the moment I am interested in the options on a table like UTF-8. In MySQL I write CREATE TABLE product ( id INT NOT NULL AUTOINCREMENT, name VARCHAR(255) NOT NULL DEFAULT '', PRIMARY KEY (id) ) DEFAULT CHARSET=UTF-8; Will this definition work in the PostgreSQL world? Is there a web page for people with MySQL exerience moving to PostgreSQL? CREATE TABLE product ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL DEFAULT '', ); Part of the issue is the way Ruby on Rails migration class enables me to add options to Rails' own abstraced DDL just like I have done in the above example. Other ways of adding options might be tricky. With ActiveRecord::Migration: # db/migrate/1_initial.rb class Initial ActiveRecord::Migration def self.up create_table :products do |t| t.column :name, :string, :default = '' end end # drop all tables 'rake migrate VERSION=0' def self.down drop_table :products end end # Run from main Rails directory rake migrate Using either plain SQL like above or AR::Migrate will generate the same table structure. Cheers, -Robby -- /** * Robby Russell, Founder.Developer.Geek * PLANET ARGON, Rails Development, Consulting Hosting * Portland, Oregon | p: 503.351.4730 | f: 815.642.4068 * www.planetargon.com | www.robbyonrails.com * Programming Rails | www.programmingrails.com ***/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Moving from MySQL to PostgreSQL with Ruby on Rails.
On Thu, Nov 17, 2005 at 08:48:45AM -0800, Peter Michaux wrote: Hi, I'm just new to the PostgreSQL world. I've been using MySQL but I want to develop a Ruby on Rails application that can be installed on either MySQL or PostgreSQL. I don't know how much the DDL dialects vary between them. At the moment I am interested in the options on a table like UTF-8. In MySQL I write CREATE TABLE product ( id INT NOT NULL AUTOINCREMENT, name VARCHAR(255) NOT NULL DEFAULT '', PRIMARY KEY (id) ) DEFAULT CHARSET=UTF-8; CREATE TABLE product ( id SERIAL PRIMARY KEY, name TEXT NOT NULL /* name isn't your greatest idea because it's a keyword. * http://www.postgresql.org/docs/current/static/sql-keywords-appendix.html * A more descriptive word or pair of words would be good here. * There is no DEFAULT clause because the database should throw an * error if somebody tries to INSERT a NULL here, not march onward. */ ); /* You might also want this: */ CREATE UNIQUE INDEX idx_uniq_product_name ON product(LOWER(TRIM(name))); Will this definition work in the PostgreSQL world? Is there a web page for people with MySQL exerience moving to PostgreSQL? Here are a couple. The first is a general how to convert from other things, while the second is MySQL specific. :) http://techdocs.postgresql.org/#convertfrom http://www.in-nomine.org/~asmodai/mysql-to-pgsql.html Part of the issue is the way Ruby on Rails migration class enables me to add options to Rails' own abstraced DDL just like I have done in the above example. I can't say I think it's a good idea to have abstracted or portable DDL. It's always expensive and difficult to maintain because you're either writing the DDL, etc. several times, or you're pushing functionality up into middleware where it may not belong. Pick one database back-end and stick with it. It's ever so much easier to deal with. OK, that's my $.02 :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Moving from MySQL to PostgreSQL with Ruby on Rails.
On Thu, Nov 17, 2005 at 09:23:51 -0800, Robby Russell [EMAIL PROTECTED] wrote: CREATE TABLE product ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL DEFAULT '', ); And depending on why you chose VARCHAR(255), you may really want to use TEXT instead. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Moving from MySQL to PostgreSQL with Ruby on Rails.
On Thu, 2005-11-17 at 15:10 -0600, Bruno Wolff III wrote: On Thu, Nov 17, 2005 at 09:23:51 -0800, Robby Russell [EMAIL PROTECTED] wrote: CREATE TABLE product ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL DEFAULT '', ); And depending on why you chose VARCHAR(255), you may really want to use TEXT instead. Mainly because, Rails will generate forms based on the data types differently. A text field - VARCHAR... textarea - TEXT. Sort of a meta-approach for Rails-based scaffolding generator. Not required, but it'll speed up the process and limit the number of chars that you can stick into a text field opposed to a text area. Robby -- /** * Robby Russell, Founder.Developer.Geek * PLANET ARGON, Rails Development, Consulting Hosting * Portland, Oregon | p: 503.351.4730 | f: 815.642.4068 * www.planetargon.com | www.robbyonrails.com * Programming Rails | www.programmingrails.com ***/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
Michael Chaney wrote: On Thu, Mar 04, 2004 at 10:50:50AM -0500, Tom Lane wrote: If I understood the requirements correctly, it might be sufficient to put a unique index on (id1,id2). If two transactions simultaneously try to insert for the same id1, one would get a duplicate-index-entry failure, and it would have to retry. The advantage is you take no table-wide lock. So if the normal usage pattern involves lots of concurrent inserts for different id1 values, you'd come out ahead. Whether that applies, or is worth the hassle of a retry loop in the application, I can't tell from the info we've been given. Not a bad idea, but probably best to move it into a stored procedure in that case. But there isn't any exception handling - the duplicate-index-entry failure will abort the procedure and return to the client with an error. The only place to loop would be in the client AFAICS. Mike Mascari ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
On Thu, Mar 04, 2004 at 10:50:50AM -0500, Tom Lane wrote: If I understood the requirements correctly, it might be sufficient to put a unique index on (id1,id2). If two transactions simultaneously try to insert for the same id1, one would get a duplicate-index-entry failure, and it would have to retry. The advantage is you take no table-wide lock. So if the normal usage pattern involves lots of concurrent inserts for different id1 values, you'd come out ahead. Whether that applies, or is worth the hassle of a retry loop in the application, I can't tell from the info we've been given. Not a bad idea, but probably best to move it into a stored procedure in that case. Michael -- Michael Darrin Chaney [EMAIL PROTECTED] http://www.michaelchaney.com/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
Harald Fuchs wrote: In article [EMAIL PROTECTED], "scott.marlowe" [EMAIL PROTECTED] writes: On Tue, 2 Mar 2004, [UTF-8] Paulovi Michal wrote: how you solve the problem with multilevel autoicrement? In MySQL you create table with col1, col2. Col 2 is AUTOICREMENT and you have to create UNIQUE INDEX (Col1, Col2). If you insert to this table for col1 volume 1, col2 automaticaly increase by one. Example: Insert into table values (1); Insert into table values (1); Insert into table values (2); Insert into table values (1); Insert into table values (2); I did this in MySQL and got this: create table test (id1 int, id2 int auto_increment, primary key(id2)); Query OK, 0 rows affected (0.00 sec) mysql alter table test add unique index (id1, id2); Query OK, 0 rows affected (0.09 sec) Records: 0 Duplicates: 0 Warnings: 0 You can't have a multi-level autoincrement if you make the second level unique. Use the following instead: create table test (id1 int, id2 int auto_increment, primary key(id1,id2)); Note that this trick works only for the MyISAM and BDB table types, not for InnoDB. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Server. http://www.nod32.com You don't build secent level unique You have to create uniqe index under both levels (first and second) together. But in MySQL there is no problem. I alredy have table with mulitlevel autoincrement (in MySQL) but now I want move this to PostgreSQL 7.1, and i have problem with this. It doesn't work :-
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
On Wed, Mar 03, 2004 at 18:12:18 +0100, Paulovi?? Michal [EMAIL PROTECTED] wrote: You don't build secent level unique You have to create uniqe index under both levels (first and second) together. But in MySQL there is no problem. I alredy have table with mulitlevel autoincrement (in MySQL) but now I want move this to PostgreSQL 7.1, and i have problem with this. It doesn't work :- That isn't an appropiate use of sequences. You should only be using their uniqeness. If the values are supposed to have some other semantics you should be using another mechanism. Also Posgtesql 7.1 is very old. You really should upgrade to something more recent. 7.4.2 is due out in a few days. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
On Wed, 3 Mar 2004, [UTF-8] Paulovič Michal wrote: Yes I know, But how you do this at PgSQL OK, I just read the response where someone showed me how to make such a table in mysql. What an odd, and non-intuitive behaviour that is. Anyway, first off, upgrade your version of postgresql to 7.4.x . 7.1 is VERY old, and is no longer maintained. IT would suck to develop all this for 7.1 only to find out some minor bug fix gets in your way of upgrading. Next, what you need is a before trigger that will take any row being inserted, select the max(id2) where id1 = whatwereinserting adds one to it and makes that the new id2. Look up before triggers. plpgsql is a good language to do this in. Note that on large tables it WILL BE SLOW. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
Bruno Wolff III wrote: On Wed, Mar 03, 2004 at 18:12:18 +0100, Paulovi?? Michal [EMAIL PROTECTED] wrote: You don't build secent level unique You have to create uniqe index under both levels (first and second) together. But in MySQL there is no problem. I alredy have table with mulitlevel autoincrement (in MySQL) but now I want move this to PostgreSQL 7.1, and i have problem with this. It doesn't work :- That isn't an appropiate use of sequences. You should only be using their uniqeness. If the values are supposed to have some other semantics you should be using another mechanism. Also Posgtesql 7.1 is very old. You really should upgrade to something more recent. 7.4.2 is due out in a few days. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) Information from NOD32 This message was checked by NOD32 Antivirus System for Linux Mail Server. http://www.nod32.com Yes, :( I have thought about this issue. Upgrade of PgSQL might by first step - probably. In other node at this formu other colegue give me an idea but it works on 7.2 and newer. Yes I have to try negotiate with provider of my DB enviroment for upgrading version of PgSQL. tnx a lot for all ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
On Wed, Mar 03, 2004 at 06:45:56AM +0100, Paulovi?? Michal wrote: Yes I know, But how you do this at PgSQL You have to lock the table exclusively, get the max value for your particular id1, increment it, insert the row, and commit: begin; lock table test in exclusive mode; insert into test values (1,(select max(id2) from test where id1=1)+1); commit; It's not pretty, and it'll probably slow down as the table grows. MySQL probably suffers the same problem. Michael -- Michael Darrin Chaney [EMAIL PROTECTED] http://www.michaelchaney.com/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
Michael Chaney [EMAIL PROTECTED] writes: begin; lock table test in exclusive mode; insert into test values (1,(select max(id2) from test where id1=1)+1); commit; It's not pretty, and it'll probably slow down as the table grows. As-is, that will definitely get pretty slow on large tables. You could avoid the slowdown with the standard hack for replacing max() with an index probe: insert into test values (1, (select id2+1 from test where id1=1 order by id1 desc, id2 desc limit 1) ); This will be fast if there is a double-column index on (id1, id2). regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: Database metadata queries (WAS Re: [GENERAL] Moving from MySQL to PGSQL....some questions)
On Mon, Mar 01, 2004 at 11:09:32 -0600, Shawn Harrison [EMAIL PROTECTED] wrote: Would it be worthwhile to move many of these \d queries into the system schema, as views on various system tables? I've thought that it would be very useful to be able to access these things through the web or other clients. I could see the benefit of providing users with a consistent interface to such database metadata, no matter what client one is using. (OTOH, one could argue, learning to do that is a pgsql rite-of-passage. ;- ). If you are using 7.4.x look at the information_schema schema. This is going to provide a stable way to get meta data. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] Moving from MySQL to PGSQL....some questions
Michael Chaney wrote: One other note, for those converting a database from MySQL to PostgreSQL, I have a table creation conversion script here: http://www.michaelchaney.com/downloads/m2p.pl I know that two come with PostgreSQL in the contrib directory, but I wrote this because those two didn't do what I needed. With this, you should be able to take the MySQL table creation scripts (as created by mysqldump --tab=x) and directly build the tables and load the data into a PostgreSQL db with little effort. Please share what yours does that the /contrib doesn't, and ideally, send in a patch or let us add your version to /contrib. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] Moving from MySQL to PGSQL....some questions (multilevel
how you solve the problem with multilevel autoicrement? In MySQL you create table with col1, col2. Col 2 is AUTOICREMENT and you have to create UNIQUE INDEX (Col1, Col2). If you insert to this table for col1 volume 1, col2 automaticaly increase by one. Example: Insert into table values (1); Insert into table values (1); Insert into table values (2); Insert into table values (1); Insert into table values (2); Result is: 1,1 1,2 2,1 1,3 2,2 How you convert this functionality from MySQL to PgSQL??? -- Bruce Momjian wrote: Michael Chaney wrote: One other note, for those converting a database from MySQL to PostgreSQL, I have a table creation conversion script here: http://www.michaelchaney.com/downloads/m2p.pl I know that two come with PostgreSQL in the contrib directory, but I wrote this because those two didn't do what I needed. With this, you should be able to take the MySQL table creation scripts (as created by mysqldump --tab=x) and directly build the tables and load the data into a PostgreSQL db with little effort. Please share what yours does that the /contrib doesn't, and ideally, send in a patch or let us add your version to /contrib. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Moving from MySQL to PGSQL....some questions
In PGAdmin III -- you might want to UNCHECK the Display system objects option under the Display menu option -- this will prevent you from seeing all of the non-public schema's and limit your view in PGAdmin to just the databases you created... Most people dont really need to dink around with the system tables anyway... As you probably noticed -- postgreSQL is a different beast than MS Access and mySQL -- postgreSQL is a true RDBMS like Sybase, Orale, and SQL Server... postgrSQL is a true 'client/server' RDBMS -- it does not contain it's own GUI client like MS Access postgreSQL is NOT just a high-powered version of MS Access or mySQL -- there are quite a few differences -- Not to be rude -- but the postgreSQL docs (the Preface, Tutorial, and SQL Language sections) would be good for you to read... -- Greg Patnude / The Digital Demention 2916 East Upper Hayden Lake Road Hayden Lake, ID 83835 (208) 762-0762 Karam Chand [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello I have been working with Access and MySQL for pretty long time. Very simple and able to perform their jobs. I dont need to start a flame anymore :) I have to work with PGSQL for my companies current project. I have been able to setup postgresql in my rh box and i can connect and work with psql. I even downloaded pgadmin III so that i can get to work with a GUI interface. As I starting...I see the architecture of PGSQL is quite complex...or thats what I feelmaybe its for good :) Here are some of my doubts : 1.) What is template1 and template0? I assume these are system databases. Am I right? 2.) When I create a database using CREATE DATABASE stmt. a new DB is created where it has 4 schemas and around 100 tables. These are the system tables keeping information about everything in the database? I hope I am correct :) 3.) To get all the database is the server we use query like - select datname from pg_database I means that there exists a table pg_database in all the database and all the pg_database table(s) are updated whenever a user issues CREATE DATABASE stmt. Why I am saying so coz in PgAdmin III i can see these tables in all the databases? 4.) I couldnot find any query to change the context of database like in MySQL : use database; or am i missing something? 5.) In MySQL, there are many command like show tables, show databases etc. to get object details. I cant see anything similar in PGSQL. After searching the net i find that i have to execute certain queries to fetch those queries. Is this the only way? Any help would be appreciated. Regards Karam __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Moving from MySQL to PGSQL....some questions
Karam Chand [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 5.) In MySQL, there are many command like show tables, show databases etc. to get object details. I cant see anything similar in PGSQL. After searching the net i find that i have to execute certain queries to fetch those queries. Is this the only way? One easy way is to use the psql command line program and the \d command. It lists all your tables, lists all the columns in a table, etc. Karl [EMAIL PROTECTED] Free Software: You don't pay back, you pay forward. -- Robert A. Heinlein ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Moving from MySQL
On 09/08/2003 01:41 Simon Windsor wrote: Hi I am sorry for mailing this list directly, but I am planning to migrate a web application from MySQL to Postgres. I am aware of a number of applications to help in this process, ie my2pg, etc. The biggest stumbling block I face is replication. What facilities exist within Postgres to replicate data from one instance to another? There are several replication mechanisms available for PostgreSQL. The two shipped with it are dbmirror and rserv. I believe that rserv will shortly be replaced by erserv, which is based on rsev and uses Java instead of perl. Which version of Postgres would people to recommend? The latest production release is 7.3.4. I'd recoomend using that. HTH -- Paul Thomas +--+-+ | Thomas Micro Systems Limited | Software Solutions for the Smaller Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +--+-+ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[GENERAL] Moving from MySQL
Hi I am sorry for mailing this list directly, but I am planning to migrate a web application from MySQL to Postgres. I am aware of a number of applications to help in this process, ie my2pg, etc. The biggest stumbling block I face is replication. What facilities exist within Postgres to replicate data from one instance to another? Which version of Postgres would people to recommend? Many thanx Simon WindsorEmail: [EMAIL PROTECTED]Tel: 01454 617689Mob: 07720 447385This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [GENERAL] moving from mySQL to pgsql, need a bit of help (perl)
Ed Loehrwrote:
I believe DBI/DBD does this for you:
while ($row_href = $sth-fetchrow_hashref)
{
push( @taghash, $row_href);
}
Don't do that! Each hashref in that array will point to the same hash in some
future version of the DBI. You should do this instead:
while($row=$sth-fetchrow_hashref){
push @taghash,{%$row};
}
Or, better yet:
$taghash=$sth-fetchall_arrayref({});
to get everything all in one go.
--
Peter Haworth [EMAIL PROTECTED]
"Master, does Emacs have the Buddha nature?" the novice asked.
The Chief Priest had been in the temple for many years and could be
relied upon to know these things. He thought for several minutes before
replying, "I don't see why not. It's got bloody well everything else."
[GENERAL] moving from mySQL to pgsql, need a bit of help (perl)
Hello, I'm trying to move from mySQL to PostgreSQL, and I've got to port a
web app over that's written in perl. It uses the DBD/DBI stuff, and works
great so far with mySQL. I've got a very specific question relating to
pulling data out of a database, I hope this is the correct forum for it.
Here goes:
I have a database set up with a table that has 3 fields in it:
userid
username
userdata
In my current code (perl/mySQL), I execute the following query: "SELECT *
from table_name" - then use the following code to put it in a hash:
$j = 0;
while (@row = $sth-fetchrow_array)
{
for ($i = 0; $i $fields; $i++)
{
$taghash[$j]{$$fieldnames[$i]} = $row[$i];
}
$j++;
}
What I end up with is an array of hashes containing all the table data.
Each element in the array is a hash called $taghash[$i], and the fields can
be accessed via $taghash[$i]{'userid'}, $taghash[$i]{'username'}, and
$taghash[$i]{'userdata'}. $fields and $fieldnames are variables created by a
subroutine I wrote which is called after the query is executed. $fields is
simply the number of fields in the table, and $fieldnames is an array
containing the names of the columns in the table, in order, produced by
"$fieldnames = $sth-{NAME};" HERE is the problem. The PostgreSQL DBI/DBD
doesn't seem to support this. I'm looking for something that returns the
names of the columns in the table, so I can duplicate my code without
changing too much. Is there anything available to do this? I've yet to find
it in the documentation, though I may have simply missed it, as I'm new to
PostgreSQL... Any help is appreciated...
Thanks,
Matt ([EMAIL PROTECTED])
Re: [GENERAL] moving from mySQL to pgsql, need a bit of help (perl)
Matt Housh wrote:
In my current code (perl/mySQL), I execute the following query: "SELECT *
from table_name" - then use the following code to put it in a hash:
$j = 0;
while (@row = $sth-fetchrow_array)
{
for ($i = 0; $i $fields; $i++)
{
$taghash[$j]{$$fieldnames[$i]} = $row[$i];
}
$j++;
}
What I end up with is an array of hashes containing all the table data.
Each element in the array is a hash called $taghash[$i], and the fields can
be accessed via $taghash[$i]{'userid'}, $taghash[$i]{'username'}, and
$taghash[$i]{'userdata'}. $fields and $fieldnames are variables created by a
subroutine I wrote which is called after the query is executed. $fields is
simply the number of fields in the table, and $fieldnames is an array
containing the names of the columns in the table, in order, produced by
"$fieldnames = $sth-{NAME};" HERE is the problem. The PostgreSQL DBI/DBD
doesn't seem to support this. I'm looking for something that returns the
names of the columns in the table, so I can duplicate my code without
changing too much. Is there anything available to do this? I've yet to find
it in the documentation, though I may have simply missed it, as I'm new to
PostgreSQL... Any help is appreciated...
I believe DBI/DBD does this for you:
while ($row_href = $sth-fetchrow_hashref)
{
push( @taghash, $row_href);
}
Regards,
Ed Loehr
