[BUGS]

Logged by: Michael Kopljan email: ad...@navigator-info.com PostgreSQL version: 8.4.2 Operating system: Windows 2008 Server Description: bug in string comparison Details: -- Drop DROP TABLE IF EXISTS "public"."test" ; -- Definition CREATE TABLE "public"."test" ( "id_robe" INTEGER NOT NULL, "s

Re: [BUGS] bug in string comparison

"kopljan" writes: > Description: bug in string comparison What this sounds like is you are using two different locale settings in the 8.2 and 8.4 installations. Postgres' string comparisons follow whatever the rules of the locale are. Try "show lc_collate" to see what the setting is. In 8.2 th

[BUGS] bug in string comparison

Logged by: Michael Kopljan email: ad...@navigator-info.com PostgreSQL version: 8.4.2 Operating system: Windows 2008 Server Description: bug in string comparison Details: -- Drop DROP TABLE IF EXISTS "public"."test" ; -- Definition CREATE TABLE "public"."test" ( "id_robe" INTEGER NOT NULL, "s

Re: [BUGS] Diffrent column ordering after dump/restore tables with INHERITS

Tom Lane escribió: > 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 > child column orders inconsistent. Would you prefer that we restricted

Re: [BUGS] Diffrent column ordering after dump/restore tables with INHERITS

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 child column orders inconsistent. Would you prefer that we restricted ALTER TABLE to refuse to perfor

Re: [BUGS] Diffrent column ordering after dump/restore tables with INHERITS

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 be lost. If you > subse

Re: [BUGS] BUG #5347: initdb does not work when a data directory has been deleted

David Andersen writes: > Thank you for your answer. The error message states: > "initdb: directory "../data" exists but is not empty" > This is wrong. ../data does not exist I really, really doubt that the code gets that test wrong. Your message suggested that you might have typed ..\data when y

Re: [BUGS] BUG #5347: initdb does not work when a data directory has been deleted

Hi Tom, Thank you for your answer. The error message states: "initdb: directory "../data" exists but is not empty" This is wrong. ../data does not exist It then states: "If you want to create a new database system, either remove or empty the directory "../data" or run initdb with an argument othe

Re: [BUGS] BUG #5347: initdb does not work when a data directory has been deleted

"David Andersen" writes: > [ initdb fails with ] > initdb: directory "../data" exists but is not empty > If you want to create a new database system, either remove or empty > the directory "../data" or run initdb > with an argument other than "../data". This is not a bug. It's an intentional saf

Re: [BUGS] Diffrent column ordering after dump/restore tables with INHERITS

2010/2/26 Oleg Serov : > Up! Anybody will answer about the patch? The patch causes the inheritance history to be lost. If you subsequently drop the column form the parent it'll be kept on the child because it was explicitly declared when you created the child. In the original structure if you drop

[BUGS] BUG #5347: initdb does not work when a data directory has been deleted

The following bug has been logged online: Bug reference: 5347 Logged by: David Andersen Email address: david.ander...@andersen-innovation.com PostgreSQL version: 8.4.2 Operating system: Windows 7 64-bit Description:initdb does not work when a data directory has been d

Re: [BUGS] Diffrent column ordering after dump/restore tables with INHERITS

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: > >> when i done dump->rest

Re: [BUGS] Bug in PL/PgSQL "SELECT .. INTO" statement parser

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: > > > > CREATE TABLE test2 ( > >id BIGINT, > >

Re: [BUGS] Bug in triggers

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 ( > "type" VARCHAR, >"type2" V

Re: [BUGS] Bug in procedure When you modificate table

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 ( 'bug1', 'bug2', 'bug3' ); > > CREATE TABLE "bug

Re: [BUGS] BUG #4673: pl/PgSQL: Bug, when updating changed composite types.

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