MySQL to PostGres conversion

[Th3L0rD]

Hi,
I'm porting some php code from mysql to postgres but I canàt find
something equivalent to mysql_select_db (). I use this function to switch
from a DB on machine 1 to a db on machine 2. Is there something similar for
pg ? I'm using php 4.2.2 on a linux box

thanks

thl

[Terence]

Re: MySQL to PostGres conversion

Th3L0rD wrote:
[color=blue]
> Hi,
> I'm porting some php code from mysql to postgres but I canàt find
> something equivalent to mysql_select_db (). I use this function to switch
> from a DB on machine 1 to a db on machine 2. Is there something similarfor
> pg ? I'm using php 4.2.2 on a linux box
>
> thanks
>
> thl
> [/color]

The answer lies in examining the [xxx]_connect() functions from mysql
and pg.
You will see that the datbase name is required as part of the pg connect
string. It is not required for mysql because you choose which database
at runtime. Postgres does not allow you to change which database you are
using at runtime for the given **connection resource**.

There is also no Postgres command I am aware of that you can execute to
change databases

http://www.postgresql.org/docs/current/interactive/sql-commands.html

In your previous mysql based code, on what basis do you choose to switch
databases?

[R. Rajesh Jeba Anbiah]

Re: MySQL to PostGres conversion

Th3L0rD <th3l0rd@nospam .katamail.com> wrote in message news:<Xns943D8A 5B6B0BAth3l0rdn ospamkatamai@63 .223.5.254>...[color=blue]
> Hi,
> I'm porting some php code from mysql to postgres[/color]

Why not try http://mp2p.mikekohn.net/ ?

---
"Dying is an art, like everything else"---Sylvia Plath
Email: rrjanbiah-at-Y!com

[Michael Fuhr]

Re: MySQL to PostGres conversion

ng4rrjanbiah@re diffmail.com (R. Rajesh Jeba Anbiah) writes:
[color=blue]
> Th3L0rD <th3l0rd@nospam .katamail.com> wrote in message news:<Xns943D8A 5B6B0BAth3l0rdn ospamkatamai@63 .223.5.254>...[color=green]
> > Hi,
> > I'm porting some php code from mysql to postgres[/color]
>
> Why not try http://mp2p.mikekohn.net/ ?[/color]

Or use dbx, avoid using database-specific features, and use a subset
of SQL that's likely to work everywhere. Done correctly, porting
code from one DBMS to another can involve nothing more than changing
the arguments to dbx_connect().

http://www.php.net/manual/en/ref.dbx.php

With dbx you might lose functionality that the database-specific
APIs provide, but if you've ever had to work with multiple DBMSs
or if you've had to port a lot of code from one DBMS to another,
then you might appreciate having a common API.

If dbx is too lacking, then you could write your own module to
provide the functionality you want while hiding the database-specific
details from the application. To port from one DBMS to another,
you'd just change or add a little code in the module instead of
having to change code throughout the application.

--
Michael Fuhr

http://www.fuhr.org/~mfuhr/

[R. Rajesh Jeba Anbiah]

Re: MySQL to PostGres conversion

mfuhr@fuhr.org (Michael Fuhr) wrote in message news:<3fc2f398$ 1_4@omega.dimen sional.com>...[color=blue]
> ng4rrjanbiah@re diffmail.com (R. Rajesh Jeba Anbiah) writes:
>[color=green]
> > Th3L0rD <th3l0rd@nospam .katamail.com> wrote in message news:<Xns943D8A 5B6B0BAth3l0rdn ospamkatamai@63 .223.5.254>...[color=darkred]
> > > Hi,
> > > I'm porting some php code from mysql to postgres[/color]
> >
> > Why not try http://mp2p.mikekohn.net/ ?[/color]
>
> Or use dbx, avoid using database-specific features, and use a subset
> of SQL that's likely to work everywhere. Done correctly, porting
> code from one DBMS to another can involve nothing more than changing
> the arguments to dbx_connect().[/color]

So, it's not a wrapper and so I couldn't understand the use of dbx.
If you want to move to another DB, you need to change the whole code
with some search and replace...

My knowledge is limited to native MySQL and PEAR. But, I hate PEAR
because of it's messy. Most often I would use native codes; sometimes
depending upon the project I would go for my own wrapper DB class.

I would like to know the real use of dbx. It seems that you've used
dbx successfully... that's why I've decided to ask you the __real__
benefit of dbx.

TIA

---
"Dying is an art, like everything else"---Sylvia Plath
Email: rrjanbiah-at-Y!com

[Michael Fuhr]

Re: MySQL to PostGres conversion

ng4rrjanbiah@re diffmail.com (R. Rajesh Jeba Anbiah) writes:
[color=blue]
> mfuhr@fuhr.org (Michael Fuhr) wrote in message news:<3fc2f398$ 1_4@omega.dimen sional.com>...[color=green]
> >
> > Or use dbx, avoid using database-specific features, and use a subset
> > of SQL that's likely to work everywhere. Done correctly, porting
> > code from one DBMS to another can involve nothing more than changing
> > the arguments to dbx_connect().[/color]
>
> So, it's not a wrapper and so I couldn't understand the use of dbx.
> If you want to move to another DB, you need to change the whole code
> with some search and replace...[/color]

If the application is already written using a database-specific
API, then yes, you have to make global substitutions when porting
to a new database.
[color=blue]
> I would like to know the real use of dbx. It seems that you've used
> dbx successfully... that's why I've decided to ask you the __real__
> benefit of dbx.[/color]

The benefit of using dbx or any other database abstraction layer
is that you change almost nothing when porting an application to
use a different DBMS: ideally you'd change only one line, the line
that connects to the database. The rest of the application doesn't
know or care whether the database is MySQL, PostgreSQL, Oracle,
Sybase, or whatever. This makes the application more portable and
easier to maintain.

The disadvantage of database abstraction layers is that you can
lose access to features that are by their nature database-specific.
The code might also be less efficient due to the overhead imposed
by the abstraction layer.

Whether the advantages of using a database abstraction layer outweigh
the disadvantages depends on the environment and your priorities.
If the code might have to use different DBMSs, and if the cost of
modifying the code and then testing the changes is expensive, then
using an abstraction layer might be preferable. On the other hand,
if the application is likely to run only in an environment that's
already heavily committed to a particular DBMS, then you might
prefer to use that DBMS's API for efficiency and to gain full access
to its features.

--
Michael Fuhr

http://www.fuhr.org/~mfuhr/

[Th3L0rD]

Re: MySQL to PostGres conversion

> I'm porting some php code from mysql to postgres but I canàt find[color=blue]
> something equivalent to mysql_select_db (). I use this function to
> switch from a DB on machine 1 to a db on machine 2. Is there something
> similar for pg ? I'm using php 4.2.2 on a linux box[/color]
thanks to all for the replies. I simply modified the function that selects
wich DB to use to work properly with PG (I should have read better the
manual ^__^)

thanks again

thl