From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andre Maasikas <andre(dot)maasikas(at)abs(dot)ee> |
Cc: | tsarevich(at)gmail(dot)com, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Syntax Issue in Trigger Function?? |
Date: | 2004-09-28 21:56:04 |
Message-ID: | 19727.1096408564@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Andre Maasikas <andre(dot)maasikas(at)abs(dot)ee> writes:
> Without escaping it looks like v_ref := ''/'';
> dividing 2 empty strings, and indeed gives
> division by zero in psql. What dividing 2 strings is actually
> supposed to mean is not evident form the docs in the first glance.
This is a pet peeve of mine that I unfortunately forgot to do anything
about before 8.0 beta started; so it's too late for this release, unless
there is another reason for forcing initdb before final. The problem is
that the "char" type (not to be confused with CHAR(n) type) has basic
arithmetic operators defined, and since it is considered a member of the
STRING type class, these operators get selected whenever a couple of
undecorated strings are provided.
Try these on for size :-(
regression=# select '2' + '2';
?column?
----------
d
(1 row)
regression=# select 'A' * 'B';
?column?
----------
(1 row)
regression=# select '1' / '';
ERROR: division by zero
Given the one-byte precision, these operators are surely of pretty
marginal use. I'd leave 'em alone if it weren't that the type coercion
rules cause the parser to seize on these operators in cases where a "no
operator could be identified" error would be far more appropriate.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Scrappy | 2004-09-28 22:05:57 | Re: Hello |
Previous Message | ying_lu | 2004-09-28 21:28:25 | Postgresql commands to display all functions and process/connections based on a database. |