SQL code:
ROLLBACK;
BEGIN;
CREATE TYPE composite_type AS (
typename VARCHAR
);
CREATE TABLE buggy (
id BIGINT NOT NULL,
bug composite_type,
CONSTRAINT buggy_pkey PRIMARY KEY(id)
) WITH OIDS;
INSERT INTO buggy (id, bug) VALUES
(100196418052926086, NULL);
CREATE OR REPLACE
Sorry, bug is not in triggers, it is in PL/PGSQL var assign mechanism
here it is an example:
ROLLBACK;
BEGIN;
CREATE TYPE composite_type AS (
type VARCHAR,
type2 VARCHAR
);
CREATE TABLE buggy (
id BIGINT NOT NULL,
bug composite_type,
CONSTRAINT
On Fri, Sep 26, 2008 at 8:05 AM, Alex Hunsaker [EMAIL PROTECTED] wrote:
On Thu, Sep 25, 2008 at 10:22 AM, Tom Lane [EMAIL PROTECTED] wrote:
A likely bet is that this is caused by use of uninitialized memory,
which happens to have garbage rather than zeroes in it the second
time through.
Yep
Brendan Jurd [EMAIL PROTECTED] writes:
I have some thoughts on this and other issues surrounding AM/PM, but
perhaps they are better reserved for a separate thread. Might I
suggest we apply Alex's bugfix and hold off on the message changes
pending further discussion?
Agreed on separating the
On Fri, Sep 26, 2008 at 8:11 AM, Tom Lane [EMAIL PROTECTED] wrote:
Brendan Jurd [EMAIL PROTECTED] writes:
I have some thoughts on this and other issues surrounding AM/PM, but
perhaps they are better reserved for a separate thread. Might I
suggest we apply Alex's bugfix and hold off on the
On Sat, Sep 27, 2008 at 12:11 AM, Tom Lane [EMAIL PROTECTED] wrote:
Agreed on separating the message issue. What I wanted to know was
whether there are similar bugs elsewhere in to_timestamp, or whether
you're pretty sure this is the only occurrence of the coding pattern?
I'm pretty sure
Brendan Jurd [EMAIL PROTECTED] writes:
On Sat, Sep 27, 2008 at 12:11 AM, Tom Lane [EMAIL PROTECTED] wrote:
Agreed on separating the message issue. What I wanted to know was
whether there are similar bugs elsewhere in to_timestamp, or whether
you're pretty sure this is the only occurrence of
