Re: Problem with || and data types

Folks,
	I've figured out the problem here... When I have a where clause that
contains "x=(select x from y where z) || 'test'" it's interpreting this as
"(x=(select x from y where z)) || 'test'" instead of "x=((select x from y
where z) || 'test')".
	This looks like a change from 7.2.1 to 7.3.2.  Shouldn't the = operator
have pretty much the lowest precedence of any operator?
Thanks,
Peter Darley

-----Original Message-----
From: pgsql-general-owner <at> postgresql.org
[mailto:pgsql-general-owner <at> postgresql.org]On Behalf Of Peter Darley
Sent: Wednesday, April 30, 2003 12:51 PM
To: Pgsql-General
Subject: [GENERAL] Problem with || and data types

Friends,
	I've got a very bizarre and frustrating problem with concatenation and data
types.  I have a query that doesn't have a single piece of Boolean data in
it, but gives me an error that mentions a bool:

UPDATE Import_Items SET Name=(SELECT QT.Import_As FROM Question_Types QT,
Border_Type_Translation BTT WHERE QT.Value=BTT.First_Type AND
BTT.Second_Type=Border_Questions.Type) || ':' || Border_Questions.Field_Name
FROM Border_Questions WHERE 'Quantum_' || Border_Questions.Question_ID =
Import_Items.Foreign_Key AND Import_Items.Name <>(SELECT QT.Import_As FROM
Question_Types QT, Border_Type_Translation BTT WHERE QT.Value=BTT.First_Type
AND BTT.Second_Type=Border_Questions.Type) || ':' ||
Border_Questions.Field_Name

Re: dump/restore to 7.4devel giving "[archiver (db)] error returned by PQputline"

"Ron Mayer" <ron <at> intervideo.com> writes:
> I've never used tcpdump, so any pointers to what's valuable to
> you would be appreciated.

> Is 
>   tcpdump -X -x -s 8192 -i any port 5432 | tail -[a_few_thousand]
> the most useful to you?  Or are other flags better?

Sounds good for starters.

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Re: box function implemented?

wsheldah <at> lexmark.com writes:
> I think I found a glitch either in the box function or in the docs for
> postgresql 7.3.2. The online docs say that the box function can find the
> intersection box between two boxes.

Looks like it should be referring to box_intersect().  Will fix the docs
--- thanks for catching this!

> Having said all that, I have to say that postgresql's geometry functions
> are fantastic. I just came up with my first need for them, and it looks
> like they're going to really save me from writing a chunk of code and speed
> things up. Thanks!

FWIW, I don't have a whole lot of confidence in the built-in geometric
functions.  They started as an academic exercise (like the rest of
Postgres) but have not been wrung out the way the rest of the system
has.  It seems like everyone who uses them finds more bugs.  So use 'em,
by all means, but test before you trust.

You might also care to look at PostGIS, which has the intention of being
industrial-strength code.  I'm not sure what their level of wrung-out-ness
really is at the moment, but at least there are people actively working
on that code.

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Re: Problem with || and data types

"Peter Darley" <pdarley <at> kinesis-cem.com> writes:
> 	I've figured out the problem here... When I have a where clause that
> contains "x=(select x from y where z) || 'test'" it's interpreting this as
> "(x=(select x from y where z)) || 'test'" instead of "x=((select x from y
> where z) || 'test')".

Doesn't look that way from here:

regression=# explain
regression-# select f1 from int4_tbl where f1 = (select unique1 from tenk1) || 'test';
                            QUERY PLAN
-------------------------------------------------------------------
 Seq Scan on int4_tbl  (cost=0.00..1.10 rows=1 width=4)
   Filter: ((f1)::text = (($0)::text || 'test'::text))
   InitPlan
     ->  Seq Scan on tenk1  (cost=0.00..458.00 rows=10000 width=4)
(4 rows)

Whether this is a particularly sensible interpretation I dunno, but
for sure it's binding || more tightly than =.

There are related syntaxes (= ANY and so forth) that are treated like
generic operators and so would bind left-to-right in this example:

regression=# explain
regression-# select f1 from int4_tbl where f1 = any (select unique1 from tenk1) || 'test';
ERROR:  Unable to identify an operator '||' for types 'boolean' and '"unknown"'
        You will have to retype this query using an explicit cast

But AFAICT 7.2 does that the same way.

Re: Problem with || and data types

"Peter Darley" <pdarley <at> kinesis-cem.com> writes:
> ... AND Import_Items.Name <>(SELECT QT.Import_As FROM
> Question_Types QT, Border_Type_Translation BTT WHERE QT.Value=BTT.First_Type
> AND BTT.Second_Type=Border_Questions.Type) || ':' ||
> Border_Questions.Field_Name

Actually, the first operator you have there is "<>" not "=".  "<>" is
considered a generic Op, just like "||", so the binding will be left-to-
right.  AFAIK this was the same in 7.2 and for a good ways before.

In short, you need some parentheses.

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo <at> postgresql.org

Join Stallman and Software SMEs to refuse sofware patents

Dear members of the PostgreSQL Community,

I registered the congress at the European Parliament (Brussels Thursday 8 May 
2003 9:00-12:00 room ASP 1G2) to explain in 2 minutes how PostgreSQL and some 
of its offshots (pgAdmin & PhpPgAdmin) can benefit the economy.

If you are interested in joining us, please contact directly Laurence van de 
Walle (Lvandewalle <at> europarl.eu.int) and CC me. A registration is needed to 
have access to the conference room, get a badge, etc...

Best regards,
Jean-Michel POURE
******************************************************************************

Join Stallman and Software SMEs to refuse sofware patents !

On May 8 morning in European Parliament in Brussels, innovative software
companies such as MySQL, Galeco, Ilog, Opera ... will gather with Richard
Stallman and MEPs from the Greens-efa Group to voice their concerns on the
implications of software patents on SMEs.

Software are currently protected by copyright but there is a project for a
European directive to legalize patents on software (com 2002-092). Although
many Members of Parliament are aware that the patent system is not suitable 
for sofware, the rapporteur Arlene McCarthy (UK, Labour) is in favour. If 
Europe would adopt a system similar to the American system, 30.000 software 
patents waiting to be legalized would be inforced. Patents favour huge 
companies that can affoard a legal department, therefore harming small and 
medium-sized enterprises that create most of the innovation in the IT field. 
Patents are expensive, cause a lot of administrative work, are granted slowly 

Re: [HACKERS] Join Stallman and Software SMEs to refuse sofware patents

While you are there perhaps you can make them aware of this absurdity

http://www.kslaw.com/library/articles.asp?1063

----- Original Message ----- 
From: "Jean-Michel POURE" <jm.poure <at> freesurf.fr>
To: <pgsql-announce <at> postgresql.org>; <pgsql-advocacy <at> postgresql.org>;
<pgadmin-hackers <at> postgresql.org>; <phppgadmin-devel <at> lists.sourceforge.net>;
<pgsql-hackers <at> postgresql.org>; "pgsql-general"
<pgsql-general <at> postgresql.org>
Sent: Thursday, May 01, 2003 8:14 AM
Subject: [HACKERS] Join Stallman and Software SMEs to refuse sofware patents

> Dear members of the PostgreSQL Community,
>
> I registered the congress at the European Parliament (Brussels Thursday 8
May
> 2003 9:00-12:00 room ASP 1G2) to explain in 2 minutes how PostgreSQL and
some
> of its offshots (pgAdmin & PhpPgAdmin) can benefit the economy.
>
> If you are interested in joining us, please contact directly Laurence van
de
> Walle (Lvandewalle <at> europarl.eu.int) and CC me. A registration is needed to
> have access to the conference room, get a badge, etc...
>
> Best regards,
> Jean-Michel POURE
>
****************************************************************************

postgres connections to database

Re: Buffer Cache question....

On Wed, Apr 30, 2003 at 03:09:52PM -0600, scott.marlowe wrote:
> What about commit_siblings and commit_delay?  I haven't really played a 
> lot with those.  I would think increasing the commit delay and the number 
> of siblings should give better, but slightly bursty performance.

This depends very heavily on your actual traffic.  If you have
primarily write activity, it is a definite advantage, because you get
a boost from ganging writes to disk.  If your traffic leans more
toward reads, I find that increasing these settings is a net loss:
you just end up waiting for nothing.

BTW, it is tricky to construct a correct model load to test this,
because you have to model both the load and its distribution.

A

--

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<andrew <at> libertyrms.info>                              M2P 2A8
                                         +1 416 646 3304 x110

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Join Stallman and Software SMEs to refuse

Tim Hawkins wrote:

> While you are there perhaps you can make them aware of this absurdity
> 
> http://www.kslaw.com/library/articles.asp?1063

I had to remind myself that today was May 1 and not April 1. That is
the most sickening thing I've read in a long time...until I read the
letter sent by SBC to museumtour.com:

http://www2.museumtour.com/sbc.html

Mike

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo <at> postgresql.org