PG gem behaves strange. It requires live DB connection to only generate a model. How to turn it off?

I used MySQL as a backend before. Now I had to move to PG since Heroku
doesn't have MySQL and forces everyone to use their Heroku-PG database.

But PG virsion of Rails works diffidently. I cannot generate a model
without PG server running:

C:\ruby\Heroku\App>rails generate model Products

C:/RailsInstaller/Ruby1.9.3/lib/ruby/gems/1.9.1/gems/activerecord-
3.2.13/lib/active_record/connection_adapters/postgresql_ada
pter.rb:1216:in `initialize': could not connect to server: Connection
refused (0x0000274D/10061) (PG::Error)
       Is the server running on host "localhost" (127.0.0.1) and accepting
       TCP/IP connections on port 5432?

I even couldn't open Rails start page (Welcome aboard, I mean) without
database and app_development table in it being created! I had to
explicitly create them before.

How to turn off this behavior of PG? I don't want to start PG server
every time I just need to run some rails|rake task. This totally not the
same as MySQL. I didn't need MySQL server running to call rake|rails
tasks.

I used MySQL as a backend before. Now I had to move to PG since Heroku
doesn't have MySQL and forces everyone to use their Heroku-PG database.

Not really. You can run MySQL locally and use PG on Heroku.

But PG virsion of Rails works diffidently. I cannot generate a model
without PG server running:

C:\ruby\Heroku\App>rails generate model Products

Maybe it's a Windows thing? I ran that exact command in a test app
with PG not running and it was fine. Trying to access the model in a
console expectedly threw an error.

How to turn off this behavior of PG? I don't want to start PG server
every time I just need to run some rails|rake task.

Why would you start and stop it at all? If that's what you're using,
start it at boot time and forget about it.

FWIW,

Hassan Schroeder wrote in post #1107485:

Not really. You can run MySQL locally and use PG on Heroku.

I prefer to use raw sql anywhere where it not possible to use
Model.find or Model.where. So it is quite a problem for me to separate
server
and local versions.

Maybe it's a Windows thing?

Agree, maybe. They say all rake and rails tasks are so slow only on
Windows. So it can be the reason.

Why would you start and stop it at all? If that's what you're using,
start it at boot time and forget about it.

I have batch files that create a specific DB environments only when I
run them. It is more convenient to me.

It is not a big problem with PG. It was a little unexpected after MySQL.

Wins Lin wrote in post #1107488:

Hassan Schroeder wrote in post #1107485:

Not really. You can run MySQL locally and use PG on Heroku.

I prefer to use raw sql anywhere where it not possible to use
Model.find or Model.where. So it is quite a problem for me to separate
server
and local versions.

While there may be some circumstances where it may be necessary to wrote
raw SQL, doing so should be extremely rare. Arel (which the where method
derives) is a very powerful query language and AFAIK can do practically
anything that SQL can do. One major advantage of using Arel is that it
produced database agnostic queries.

I generally design my applications using SQLite in development, then
choose a production database based on my deployment needs. I make every
effort to create database agnostic code.

Maybe it's a Windows thing?

Agree, maybe. They say all rake and rails tasks are so slow only on
Windows. So it can be the reason.

Why would you start and stop it at all? If that's what you're using,
start it at boot time and forget about it.

I have batch files that create a specific DB environments only when I
run them. It is more convenient to me.

Sounds to me like you put great effort into making things less
convenient for yourself. Like developing Rails in Windows, using
database specific SQL embedded into your applications, etc.

It is not a big problem with PG. It was a little unexpected after MySQL.

I find it extremely convenient using SQLite for development, on a UNIX
based OS, and having the flexibility of choosing whatever database I
want when it comes time to deploy my applications.

But, to each his own I suppose.