On Thu, Aug 27, 2015 at 3:50 PM, Abraham Mathew <mathewanalyt...@gmail.com>
wrote:
>
> Yeah, thought that could be an issue. Unfortunately, I've had issues
> setting a normal user id and then having postgres identify the password
> associated with it. Using postgres was the only thing that worked.
>
> ## CONNECT TO LOCALHOST DATABASE:
> drv <- dbDriver("PostgreSQL")
> con <- dbConnect(drv, dbname="postgres", host='localhost',
> port='5432', user='postgres', password='brothers')
> dbDisconnect(con)
>
>
>
OK. So, looking at the above, you are saying that the user is "postgres"
and that the table "test" is in the database "postgres" (which is likely
also owned by "postgres"). I'm unsure from your response that this is
correct. Is "test" in the "postgres" data base? If not, you might get away
with:
# replace proper-database in the following with the correct data base name,
which contains the "test" table
con <- dbConnect(drv, dbname="proper-database", host="localhost",
port='5432', user='postgres', password='brothers')
Normally, when I am logged in a myself, my code usually looks a bit like:
dbname <- Sys.info['user']; # the data base name in PostgreSQL is the same
as my login id
con <- dbConnect(drv,dbname=dbname); # connect to PostgreSQL on the local
host as myself (implicit).
ds_summary(con, "test", vars=c("Age"), y=c("Class"))
In my pg_hba.conf file, I have a line like:
local all all trust
Which says that everyone coming in who are on the local host are
automatically logged in as their Linux (in my case) id.
Your code is connecting via TCPIP because you have the host= & port=
parameters. This is not normally needed for users running on the same
physical machine as the PostgreSQL data base server. So I'm too lazy to do
it [grin].
--
Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.
Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.
He's about as useful as a wax frying pan.
10 to the 12th power microphones = 1 Megaphone
Maranatha! <><
John McKown
