Re: [GENERAL] Error: Operator does not exist: "char"=integer
On Friday 19 December 2008 01:29:06 you wrote: > Aarni writes: > > "ERROR: operator does not exist: character varying = integer at > > character 286 HINT: No operator matches the given name and argument > > type(s). You might need to add explicit type casts." > > > > Quick fix to sql statements eg. > > > > ... WHERE CAST (your_char AS INTEGER) = integer ... > > ... WHERE CAST (your_char AS INTEGER) IN (1,2,3,...) > > Note that this is *not* what was happening in 8.2. There it was casting > them to text and doing a text comparison. In the case of integer and > equality they're probably equivalent. However < and > will behave quite > differently. That's why the casts disappeared -- you probably weren't > running the queries you thought you were running in 8.2 and previously. Hi Gregory, Hmm, yes I did note this. Afterwards, though. "Previously ... was automatically cast to text, for most (though not all) built-in data type ... automatic casts too often caused surprising behavior." Luckily enough, I did not get funny or unexpected results with the few queries in one particular application I had to fix for 8.3.3. Best regards, -- Aarni Ruuhimäki -- 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] Error: Operator does not exist: "char"=integer
On Thursday 18 December 2008 12:46:38 Peter Eisentraut wrote: > novnov wrote: > > I have restored a postgres 8.2.4-1 db onto a postgres 8.3.1-1 server, and > > when I try to work with a table I get this error: > > > > Error: Operator does not exist: "char" = integer > > > > Hopefully that is enough of a clue to be useful. Maybe this is the first > > time I've tried moving one of my non-trivial pg projects to a > > significantly different version of postgres; is there a conversion > > process that helps with moving between versions? > > Yes, reading the release notes. ;-) I think you will find your problem > explained there. Hi, I had similar errors here and there after moving to 8.3.3 from 8.2.x., no more automatic casts. "ERROR: operator does not exist: character varying = integer at character 286 HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts." Quick fix to sql statements eg. ... WHERE CAST (your_char AS INTEGER) = integer ... ... WHERE CAST (your_char AS INTEGER) IN (1,2,3,...) BR, -- Aarni Ruuhimäki -- 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] Annoying Reply-To
Hulou hjuvat folkenbergers und goody good peoples ute po daer in allas e oceanos / terranos, I chose to 'Reply to Mailing-List' in my preferred mail app. (Kmail on Ubuntu 8.10) I really don't know why ... but shore hope, mean sure, as in truly, this is hopefully not an annoying postage broadcastung. wink, lol, capatcha, tsajajaja, manolito! Furthermore, I am pop to(a)sting. Phonetically reversed, top posting. Puff the embers every once and a while. To have [a] flame[s] --help?. Keep on keepin' on. SamiTjahkasTjohkasny, äeeäee kenen poro, Vincentin Genen? Simmons? Gruppa? Gene? Ootsiäee ihan varma? Oks sähöstarttii, ahe! Läks, where's mi head (laughing it off)? Focus. "Remember, there's a big difference between kneeling down and bending over." -- great late FZ -- Wha'ever dad means, I think we need some standards. 1. I wish 2. I had a button that kept me from sending silly messages. 3. Whoops, still not do. Rock, Aarni Received: from mx2.hub.org ([200.46.204.254]:26819 "EHLO mx2.hub.org") by northstar.iwn.fi with ESMTP id S10843AbYJWU4D (ORCPT ); Thu, 23 Oct 2008 23:56:03 +0300 Received: from postgresql.org (unknown [200.46.204.86]) by mx2.hub.org (Postfix) with ESMTP id 2DEDA1E8229B; Thu, 23 Oct 2008 17:55:49 -0300 (ADT) Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id B161764FD71 for <[EMAIL PROTECTED]>; Thu, 23 Oct 2008 17:54:47 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 73727-01-4 for <[EMAIL PROTECTED]>; Thu, 23 Oct 2008 17:54:44 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by postgresql.org (Postfix) with ESMTP id 301A164FD93 for ; Thu, 23 Oct 2008 17:54:42 -0300 (ADT) Received: by rv-out-0506.google.com with SMTP id b25so482917rvf.43 for ; Thu, 23 Oct 2008 13:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=7Asrle/2g7OnvL+HaGS+X0l8PHMMoueNpeFTF88Jfzs=; b=cyRbNr15f00Tbu7laTnSM9nSmJhkwnqBa04eGgWN7AV9nfxSEqrCM0EhMiy0ZFPec1 PzBioeul06+v2CNCD7LDc3KiTHky2DliiA7gYedUtJcW6UJtjbeqo1CxBqEA/sM47FHO fHmhUNIJ9nh5tnfI4SejEiDdht1mgmGsdbFDM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=UIdt6g6DfV7h1z9tYcTxlUF90IFoeN6iAAH6GHrzWsp5VpluWUEIVgsZloJkDcIFeh ffuxRD9Ucq2bPWcnk2flEeLbyCQwOvDsiU5WR24JGYF5LAPugouNEKW5xeLAOnN5JA8/ V7/aUnJMkdkdCNxpLyGBxCUsJcbVKgGDdyaN0= Received: by 10.141.162.16 with SMTP id p16mr661554rvo.243.1224795281837; Thu, 23 Oct 2008 13:54:41 -0700 (PDT) Received: by 10.141.77.14 with HTTP; Thu, 23 Oct 2008 13:54:41 -0700 (PDT) Message-ID: <[EMAIL PROTECTED]> Date: Thu, 23 Oct 2008 22:54:41 +0200 From: "Dave Coventry" <[EMAIL PROTECTED]> To: "Steve Atkins" <[EMAIL PROTECTED]> Subject: Re: [GENERAL] Annoying Reply-To Cc: "pgsql-general General" In-Reply-To: <[EMAIL PROTECTED]> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Mailing-List: pgsql-general List-Archive: <http://archives.postgresql.org/pgsql-general> List-Help: <mailto:[EMAIL PROTECTED]> List-ID: List-Owner: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:pgsql-general@postgresql.org> List-Subscribe: <mailto:[EMAIL PROTECTED]> List-Unsubscribe: <mailto:[EMAIL PROTECTED]> Precedence: bulk Sender: [EMAIL PROTECTED] X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean Return-Path: <[EMAIL PROTECTED]> X-Envelope-To: <[EMAIL PROTECTED]> (uid 0) X-Orcpt: rfc822;[EMAIL PROTECTED] Original-Recipient: rfc822;[EMAIL PROTECTED] Status: R X-Status: N X-KMail-EncryptionState: X-KMail-SignatureState: X-KMail-MDN-Sent: On Thursday 23 October 2008 23:54:41 Dave Coventry wrote: > 2008/10/23 Steve Atkins <[EMAIL PROTECTED]>: > > If you don't like it (and this applies to everyone else arg
Re: [GENERAL] Shopping cart
, manufacturers, order statuses, taxes, maybe temp tables for automatic updates from suppliers ... As Jonathan said, the trick is not in getting the shop online but in the management side of it all. The public shop interface is in fact only a small proportion of the system. Anyway, we did not use cart tables. The web application stores cart information in session cookies until the point the order is finished and approved and is then written to customers, orders and order rows. Two cookies, or a cookie pair, one for the product id and one for the amounts. E.g. a cookie for products "1,234,3472,555" and a cookie for amounts "2,1,1,3" means you have 2 pcs of product id 1, 1 pcs product id 234 and so on. And as mentioned, you have the freedom to choose your preferred API, be it php, python, perl or what ever. Please (Andrus) have a look at the shop, LinuxShop, in action at http://www.linuxkauppa.fi/ It is in finnish but I think you will get the hang of it with no problems. LinuxPood / LinuxKauplus, a web shop for linux compatible hardware. With very best regards, 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 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
