On Sat, Mar 6, 2010 at 2:12 AM, Chris Travers wrote:
> On Fri, Mar 5, 2010 at 2:32 PM, Tom Lane wrote:
> > Robert Haas writes:
> >>> On Wed, Mar 3, 2010 at 9:53 PM, Robert Haas
> wrote:
> >>> It does seem weird that assigning NEW to var changes the value; I'm
> >>> not sure why that happens. I
I'm asking to fix this =)
On Wed, Mar 3, 2010 at 9:53 PM, Robert Haas wrote:
> 2010/3/3 Oleg Serov :
> >
> >
> > 2010/3/1 Robert Haas
> >>
> >> It's not obvious whether this is the same as one of the various other
> >> problems you
; NEW::TEXT THEN
> RAISE NOTICE 'var is not equals NEW';
> END IF;
>
> RETURN NEW;
> END;
> $body$
> LANGUAGE 'plpgsql';
>
> CREATE TRIGGER "t_bug" BEFORE INSERT
> ON type_row FOR EACH ROW
> EXECUTE PROCEDURE "
submitted as #5353
2010/2/26 Oleg Serov
> Hey, anybody will answer here?
>
> 2008/7/4 Oleg Serov
>
> SQL BUG CODE:
>> BEGIN;
>> SELECT version(); -- "PostgreSQL 8.3.3 on i686-redhat-linux-gnu, compiled
>> by GCC gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-14)
Submitted as #*5352 bug.*
2010/2/26 Oleg Serov
> Up. Anybody will answer on this bug report?
>
>
> 2009/1/21 Oleg Serov
>
>> Sorry, but is not important, i forgot to remove original table name
>> "chunk_ad", but is not affected to the bug..
>>
>&g
I'm think you should add some abstract-layer for handling column ordering
not as they stored at disk. It is possible?
On Fri, Feb 26, 2010 at 10:32 PM, Alvaro Herrera wrote:
> Tom Lane escribió:
> > Oleg Serov writes:
> > > So there are no simple way to do it right, a
On Fri, Feb 26, 2010 at 9:29 PM, Tom Lane wrote:
> Oleg Serov writes:
> > So there are no simple way to do it right, and it will be not fixed? Will
> > this bug appear in todo list?
>
> It's not a bug, it's just what happens when you make the parent and
>
It i
So there are no simple way to do it right, and it will be not fixed? Will
this bug appear in todo list?
On Fri, Feb 26, 2010 at 6:13 PM, Greg Stark wrote:
> 2010/2/26 Oleg Serov :
> > Up! Anybody will answer about the patch?
>
> The patch causes the inheritance history to
Up! Anybody will answer about the patch?
On Mon, Jul 6, 2009 at 11:20 AM, Oleg Serov wrote:
> How about adding this patch to postgresql it will slove the problem?
>
> On Sun, Jul 5, 2009 at 8:10 PM, Greg Stark wrote:
> > On Sun, Jul 5, 2009 at 4:28 PM, Tom Lane wrote:
> &
Up. Anybody will answer on this bug report?
2009/1/21 Oleg Serov
> Sorry, but is not important, i forgot to remove original table name
> "chunk_ad", but is not affected to the bug..
>
> 2009/1/21 Oleg Serov :
> > Here is an example:
> >
> > C
Up!, Anybody will answer on this bugreport?
On Fri, Sep 26, 2008 at 2:57 PM, Oleg Serov wrote:
> 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 (
>
Hey, anybody will answer here?
2008/7/4 Oleg Serov
> SQL BUG CODE:
> BEGIN;
> SELECT version(); -- "PostgreSQL 8.3.3 on i686-redhat-linux-gnu, compiled
> by GCC gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-14)"
> CREATE TYPE "buggy_enum_first" AS ENUM ( 'b
Hello!? anybody will fix this bug? Hey!
On Mon, Feb 23, 2009 at 5:11 PM, Oleg wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4673
> Logged by: Oleg
> Email address: sero...@gmail.com
> PostgreSQL version: 8.3.6
> Operating system: i686-redhat-linux-g
Thanks!, when it will be released on 8.3.X?
On Wed, Feb 24, 2010 at 6:17 PM, Tom Lane wrote:
> Oleg Serov writes:
> > When it could be fixed?
>
> Oh, it is fixed, but I forgot to reply to this thread about it.
> Sorry about that.
>
>rega
When it could be fixed?
On Thu, Feb 11, 2010 at 9:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> 2010/2/10 Oleg Serov :
>>> Somebody will fix this bug or not?
>
>> I'm not sure whether this is a bug.
>
> Yeah, I think it is. The problem is that exec_m
Somebody will fix this bug or not?
On Thu, Feb 4, 2010 at 7:13 PM, Oleg wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5314
> Logged by: Oleg
> Email address: sero...@gmail.com
> PostgreSQL version: 8.3/8.4
> Operating system: any
> Description:
SQL:
CREATE TABLE test (id BIGINT, id2 BIGINT, id3 BIGINT, id4 BIGINT);
INSERT INTO test SELECT i, i, i, i FROM generate_series(0, 9) i;
EXPLAIN ANALYZE SELECT ((SELECT tmp::test FROM (SELECT * FROM test
LIMIT 1) tmp)::test).*;
WILL:
QUERY PLAN
Result (cost=0.11..0.12 rows=1 width=0) (actual time
How about adding this patch to postgresql it will slove the problem?
On Sun, Jul 5, 2009 at 8:10 PM, Greg Stark wrote:
> On Sun, Jul 5, 2009 at 4:28 PM, Tom Lane wrote:
>> when i done dump->restore i
>>> have surprise,
>>> Column ordering was changed.
>>
>> This is not a bug, it's the intended beh
UMERIC,
"ad_shop_select_views" NUMERIC,
"ad_emitted" NUMERIC,
"ad_redeemed" NUMERIC,
"client_payed" NUMERIC,
"mediapartner_charged" NUMERIC,
"ad_banner_views" NUMERIC,
"id" BIGINT NOT NULL,
"interval" "prt4_stat&q
-- Dump/restore
INSERT INTO test_child_with_data
SELECT * FROM some_magic(); -- Error.
On Sun, Jul 5, 2009 at 4:48 AM, toruvinn wrote:
> On Sat, 04 Jul 2009 22:10:55 +0200, Oleg Serov wrote:
>>
>> INSERT INTO test_child_with_data
>> SELECT 1, 'test&#
If i have tables with inherits, and the
n i adding a column in to the base table, the new column will be at
the on of column list in child table, but when i done dump->restore i
have surprise,
Column ordering was changed.
Some example:
CREATE TABLE test_base (
id INT
);
CREATE TABLE test_c
Here is an example:
CREATE TABLE test2 (
id BIGINT,
chunk_id BIGINT
);
CREATE TABLE test1 (
id BIGINT
);
CREATE OR REPLACE FUNCTION "bug" () RETURNS pg_catalog.void AS
$body$
DECLARE
row_test1 test1%rowtype;
row_test2 test2%rowtype;
BEGIN
SELECT test1, chunk_ad
Sorry, but is not important, i forgot to remove original table name
"chunk_ad", but is not affected to the bug..
2009/1/21 Oleg Serov :
> Here is an example:
>
> CREATE TABLE test2 (
>id BIGINT,
>chunk_id BIGINT
> );
> CREATE TABLE test1 (
>
t;:
> Hello
>
> 2008/12/10 Oleg Serov <[EMAIL PROTECTED]>:
>> SQL:
>> CREATE TABLE second_type (
>>flag BOOLEAN
>> );
>> CREATE TABLE main_type (
>>subtype second_type
>> );
>> CREATE OR REPLACE FUNCTION "bug_in_tab
SQL:
CREATE TABLE second_type (
flag BOOLEAN
);
CREATE TABLE main_type (
subtype second_type
);
CREATE OR REPLACE FUNCTION "bug_in_tabletypes" () RETURNS pg_catalog.void AS
$body$
DECLARE
row_main_table main_type%rowtype;
BEGIN
row_main_table.subtype := NULL; -- all
SQL:
CREATE OR REPLACE FUNCTION "bug_with_triggers" () RETURNS trigger AS
$body$
BEGIN
PERFORM COALESCE(NEW.some_composite_field.field, TRUE);
END;
$body$
LANGUAGE 'plpgsql' VOLATILE CALLED ON NULL INPUT SECURITY INVOKER;
Error:
ERROR: NEW used in query that is not in a rule
QUERY: SEL
Ok, thanks... it is not a bug;
2008/10/27 hubert depesz lubaczewski <[EMAIL PROTECTED]>:
> On Mon, Oct 27, 2008 at 05:08:35PM +0300, Oleg Serov wrote:
>> I can't get hstore value by key. i have very interesting error
>
> the problem is that -> has very low priority,
I can't get hstore value by key. i have very interesting error
DEMO SQL CODE:
--
ROLLBACK;
BEGIN;
-- VERSION INFO
SELECT VERSION();
-- RESULT:
-- PostgreSQL 8.3.4 on i686-redhat-linux-gnu, compiled by GCC gcc
(GCC) 4.1.2 2
)::buggy;
IF tmp_old::text <> ROW(1, NULL)::buggy::text THEN
RAISE EXCEPTION '% <> %', tmp_old, ROW(1, NULL)::buggy;
END IF;
END;
$body$
LANGUAGE 'plpgsql' VOLATILE CALLED ON NULL INPUT SECURITY INVOKER;
WILL THROW A EXCEPTION:
ERROR: (1
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);
CRE
Yes, you are right, with record type working correct;
Thanks
2008/9/2 Tom Lane <[EMAIL PROTECTED]>
> "Oleg Serov" <[EMAIL PROTECTED]> writes:
> > But if there are some records in t_table and we romove WHERE 1=0, we will
> > have
> > ERROR: wrong reco
But if there are some records in t_table and we romove WHERE 1=0, we will
have
ERROR: wrong record type supplied in RETURN NEXT CONTEXT: PL/pgSQL function
"t_func" line 9 at RETURN NEXT
2008/9/1 Pavel Stehule <[EMAIL PROTECTED]>
> Hello
>
> 2008/9/1 Oleg Serov <[
Hello all SQL BUG CODE:
BEGIN;
SELECT version(); -- "PostgreSQL 8.3.3 on i686-redhat-linux-gnu, compiled by
GCC gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-14)"
CREATE TYPE "buggy_enum_first" AS ENUM ( 'bug1', 'bug2', 'bug3' );
CREATE TABLE "bug_table" (
"id" BIGINT NOT NULL,
"buggy_enum_field" "b
Hello.
Seems there is an error when I try to use a table with one field - composite
type, when SELECT QUERY in FOR ... LOOP instruction returns empty result.
Here are steps to reproduce:
CREATE TYPE "t_type" AS (
"a" BIGINT
);
CREATE TABLE"t_table" (
"id" BIGINT NOT NULL,
"t" "t_type",
CONSTRAIN
SQL BUG CODE:
BEGIN;
SELECT version(); -- "PostgreSQL 8.3.3 on i686-redhat-linux-gnu, compiled by
GCC gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-14)"
CREATE TYPE "buggy_enum_first" AS ENUM ( 'bug1', 'bug2', 'bug3' );
CREATE TABLE "bug_table" (
"id" BIGINT NOT NULL,
"buggy_enum_field" "buggy_enum_
35 matches
Mail list logo
