The following bug has been logged online:
Bug reference: 1197
Logged by: Eleas
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4
Operating system: Linux phantom 2.6.5-gentoo-r1 #1 Sun Jun 27 18:33:50 MSD
2004 i686 AMD Athlon(tm) Processor AuthenticAMD GNU/Linux
D
The following bug has been logged online:
Bug reference: 1198
Logged by: iDEFENSE Vendor Disclosure
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4
Operating system: Linux
Description:Linux PostgreSQL Server Input Validation Vulnerability
Details:
iDE
PostgreSQL Bugs List wrote:
> iDEFENSE has identified an input validation vulnerability in
> PostgreSQL . This vulnerability was submitted to iDEFENSE through our
> Vulnerability Contributor Program
> (http://www.idefense.com/poi/teams/vcp.jsp). iDEFENSE Labs has
> validated this vulnerability and
Folks,
Also:
This behavior was different in 7.1:
[11:02:45] darcy=# select '1'::char(4) || '-'::char(1);
[11:02:45] ?column?
[11:02:45] --
[11:02:45] 1 -
[11:02:45] (1 row)
[11:02:49] on 7.1
And there's apparently either an issue, or a change in behavior, in CHAR for
7.5:
[11
People,
Severity: Serious Annoyance
Reproducable on: 7.4.1, 7.4.3, 7.5devel
Summary: Concatination of CHAR() data type field seems to result in a TEXT
value instead of a CHAR value. Is there a reason for this?
Example:
webmergers=> select '"'::char(4) || ''::char(4) || '"'::char(4);
?colum
On Tue, Jul 06, 2004 at 03:49:14PM +1000, Luke McFarlane wrote:
> When defining a symbol on the command line with ecpg -D SYMBOL the ecpg
> preprocessor will replace that symbol with empty space in 'C' program
> space rather than limiting it to 'SQL' program space.
This indeed is a bug, but ecpg
Added to TODO:
* Fix data types where equality comparison isn't intuitive, e.g. box
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I found the cause. Equals for boxes compares only area, \do:
Josh Berkus <[EMAIL PROTECTED]> writes:
> Are these changes intentional,
Yes. We've been moving more and more steadily towards the notion that
trailing spaces in char(n) values are insignificant noise. If you think
that trailing spaces are significant, you shouldn't be using char(n)
to store the
