Re: [GENERAL] php + postgresql
On Friday 25 July 2008 15:33, you wrote:
>
> I would avoid that in favour of using $HOME/.pgpass
>
> http://www.postgresql.org/docs/8.1/interactive/libpq-pgpass.html
>
> HTH
> Tino
Hi,
Quite right you are. Or something like this?
require("/eg/unknown_path/deep_somewhere_else/dbconnect_app_name.php");
BR,
Aarni
--
Burglars usually come in through your windows.
--
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] php + postgresql
On Thursday 24 July 2008 12:41, admin wrote:
> 1.
> I ended up using pg_prepare() and pg_execute() as pg_query() alone just
> didn't seem to work. But SELECT statements seemed to be cached or
> persistent in some way, such that they "lived" beyond the life of the
> PHP script. Is there something I need to know about persistent behaviour
> in PG that doesn't exist in MySQL?
Not sure what causes this with your server but I always use something like
this, ie first connect then do your stuff and then close the connection:
require("dbconnect.inc"); // holds the $conn which is pg_connect("with
passes")
if (!$conn)
{exit("Database connection failed. Please try again." . $conn);}
$sql ="SELECT ...";
$product=pg_exec($conn,$sql);
if (!$product)
{exit("Database connection failed. Please try again.");}
while ($row = pg_fetch_row($product))
{
echo"
$row[1]
";
}
pg_close($conn);
BR,
--
Aarni
Burglars usually come in through your windows.
--
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] Postgresql Help
On Monday 21 April 2008 12:08, Monalee Bhandge wrote: > pg_ctl start -D /var/lib/pgsql/data > then error is-> > postmaster started. > Could not open directory "base" No such file or > directory. Hi, Did you initdb in that location ? Best regards, -- Aarni Ruuhimäki --- Burglars usually come in through your windows. --- -- 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] Survey: renaming/removing script binaries (createdb, createuser...)
On Wednesday 26 March 2008 16:25, Zdeněk Kotala wrote: > 1) What type of names do you prefer? > --- b) new one with pg_ prefix - pg_createdb, pg_creteuser ... > > 2) How often do you use these tools? > --- > b) one per week > > > 3) What name of initdb do you prefer? > -- -- > b) pg_initdb > > 4) How do you perform VACUUM? > - > a) vacuumdb - shell command c) autovacuum -- Aarni Ruuhimäki --- Burglars usually come in through your windows. --- -- 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] postgre vs MySQL
Hi, This has been a very interesting thread indeed. I think the popularity of any Big Name $oftware with a 'nice' price tag has also something to do with the fear of taking responsibility for your own actions and decisions. With a Big Name you can always blame them if something goes wrong instead of having to admit that it was you who actually did something stupid. But as said, popular does not necessarily equal to superior. I have used PG since RedHat 6.2 (can't remember the PG version of that time) and now use it on FC, CentOS and Ubuntu. My dbs are not large, the biggest one has sixty odd tables and the biggest table is holding now around 100.000 rows. But I have seen it reach that from zero, with version upgrades and without any real db-related problems. Best regards, -- Aarni Ruuhimäki --- Burglars usually come in through your windows. --- -- 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] pg_dumpall
On Friday 18 January 2008 14:38, Steve Clark wrote: > Thanks for everyone that replied to my query about pg_dumpall. > > > Now another question/issue - anytime I usr createdb the resulting db > ends up > with UTF-8 encoding unless I use the -E switch. Is there a way to make > the > default be sql_ascii? postgres version is 8.2.5 > > Thanks again > Steve Hi Steve, http://www.postgresql.org/docs/8.2/static/app-initdb.html Best regards, -- Aarni ---(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
[GENERAL] Recommendations for a datasync scenario ?
Hello good folks, Our php application uses browser clients and magnetic card readers to collect workmen's working times from a number of physical construction or project sites to the main database at the head office, which is online with a private ip-address. Now we have a situation where not all construction sites' offices are online or have so poor / instable connections that we can't rely on them. So we need to install a local server to collect the data. What would be a proper way to load the work time data up to the main database when a local server is online again ? Also, all the workers and sites are created and maintained at the head office so we need to get this data down. There may / will be corrections to the uploaded work time data as well. I imagine all this could be done with unique row identifiers, temp tables and shell- / sql-scripts, but why re-invent the wheel ... All servers are linux + Pg8.2. I followed the recent thread about 'replication in Postgres' but still any info on experience of similar circumstances and pointers / comments / recommendations are more than welcome. BR, -- Aarni Ruuhimäki ---(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
[GENERAL] Latin1 to UTF-8 ?
Hi, I've set up a new CentOs server with PostgreSQL 8.2.4 and initdb'ed it with UTF-8. Ok, and runs fine. I have a problem with encodings, however. And mainly with the russian cyrillic characters. When I testdumped some dbs from the old FC / Pg 8.0.2, all Latin1, I noticed that some of the dumps show in the Konqueror file browser as 'Plain Text Documents' and some as 'C++ Source Files'. Both have Latin1 as client encoding at the top of the files. Changing that gives errors, as expected. Looking in to the plain text dumps I see all cyrillic characters as Р... and these go in display fine from the new server's UTF-8 environment. Some of the 'C++' files have the cyrillics as 'îñåòèòåëåé'. Some have both 'îñåòèòåëåé' and Р... and ofcourse the 'îñåò' characters come out wrong and unreadable to the browser. (not sure if you an see single quoted ones, but they look something like hebrew or similar) I have no idea what browsers / encodings or even keyboard layouts have been used when the data has been inserted by users through their web interfaces ... I tried the -F p switch as the earlier version has no -E for dumps. Same output. Also with pg_dumpall. I tried various encodings with iconv too. So, what would be the proper way to convert the dumps to UTF-8 ? Or any other solution ? Any other tool to work with the problem files ? BR, Aarni -- Aarni Ruuhimäki ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
