Re: [BUGS] BUG #4015: uninitialized value passed as an argument to tm2timetz
On Mar 5, 2008, at 10:10 PM, Tom Lane wrote: "Ted Kremenek" <[EMAIL PROTECTED]> writes: It appears that there may be a case where the function tm2timetz is called with an uninitialized (i.e., undefined) value passed as one of its arguments (actually multiple arguments are undefined). I think you're assuming DateTimeParseError() will return, which it will not (it always throws ereport(ERROR)). Or have I missed something? regards, tom lane Thanks Tom. After your comments I looked more closely at ereport. It's a little buried, but I can see that when errstart (wrapped by ereport) is called with ERROR that it does not return. Thanks for the quick response. Ted -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
Re: [BUGS] BUG #3909: src\tools\msvc\clean.bat clears parse.h file
Has this been addressed? --- Pavel Golub wrote: > > The following bug has been logged online: > > Bug reference: 3909 > Logged by: Pavel Golub > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3RC2 > Operating system: WinXP > Description:src\tools\msvc\clean.bat clears parse.h file > Details: > > Executing clean.bat from src\tools\msvc clears src\backend\parser\parse.h > > However, in help stated: > > "Bison and Flex are required to build from CVS, but not required when > building from a release file." > > Also in src\backend\parser\Makefile we have comments: > > "# gram.c, parse.h, and scan.c are in the distribution tarball, so they > # are not cleaned here." > > Because of this bug there is no opportunity to build PostgreSQL by Visual > Studio without using Bison. > > So, may be as a workaround we may use such scheme: > 1. We have "src\backend\parser\parse.h.release" (or whatever postfix) file > 2. GenerateFiles() in Solution.pm must check if Bison is available. If so > then generate parse.h by Bison, else copy parse.h.release as parse.h > 3. When clean will be called parse.h will be deleted, but not > parse.h.release > > Regards > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
Re: [BUGS] BUG #3909: src\tools\msvc\clean.bat clears parse.h file
Yes. //Magnus On Thu, Mar 06, 2008 at 11:08:15AM -0500, Bruce Momjian wrote: > > Has this been addressed? > > --- > > Pavel Golub wrote: > > > > The following bug has been logged online: > > > > Bug reference: 3909 > > Logged by: Pavel Golub > > Email address: [EMAIL PROTECTED] > > PostgreSQL version: 8.3RC2 > > Operating system: WinXP > > Description:src\tools\msvc\clean.bat clears parse.h file > > Details: > > > > Executing clean.bat from src\tools\msvc clears src\backend\parser\parse.h > > > > However, in help stated: > > > > "Bison and Flex are required to build from CVS, but not required when > > building from a release file." > > > > Also in src\backend\parser\Makefile we have comments: > > > > "# gram.c, parse.h, and scan.c are in the distribution tarball, so they > > # are not cleaned here." > > > > Because of this bug there is no opportunity to build PostgreSQL by Visual > > Studio without using Bison. > > > > So, may be as a workaround we may use such scheme: > > 1. We have "src\backend\parser\parse.h.release" (or whatever postfix) file > > 2. GenerateFiles() in Solution.pm must check if Bison is available. If so > > then generate parse.h by Bison, else copy parse.h.release as parse.h > > 3. When clean will be called parse.h will be deleted, but not > > parse.h.release > > > > Regards > > > > ---(end of broadcast)--- > > TIP 3: Have you checked our extensive FAQ? > > > >http://www.postgresql.org/docs/faq > > -- > Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us > EnterpriseDB http://postgres.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
[BUGS] BUG #4016: Build fails in ecpglib on file extern.h
The following bug has been logged online: Bug reference: 4016 Logged by: Samuel Gilbert Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.0 Operating system: Debian GNU/Linux Etch x86_64 Description:Build fails in ecpglib on file extern.h Details: I tried to build 8.3.0 on Debian GNU/Linux Etch x86_64 with the following configure options : ./configure --prefix=/data/aq_ops/software/x86_64 --enable-thread-safety --with-pgport=5433 --with-tcl --with-perl --with-python --with-pam --with-ldap --with-openssl --with-libxml --with-libxslt Most of the build process works correctly until it gets to postgresql-8.3.0/src/interfaces/ecpg/ecpglib. It then fails while trying to compile extern.h. Here is the output : make[4]: Entering directory `/data/aq_ops/software/src/postgresql-8.3.0/src/interfaces/ecpg/ecpglib' gcc -march=opteron -mfpmath=sse -fomit-frame-pointer -Wall -pipe -O2 -I/data/odysseus/afsudev/usr/include -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic -I../include -I../../../../src/interfaces/ecpg/include -I../../../../src/interfaces/libpq -I../../../../src/port -I../../../../src/include -D_GNU_SOURCE -I/usr/include/libxml2 -c -o execute.o execute.c In file included from execute.c:26: extern.h:55: error: field 'statement_type' has incomplete type execute.c: In function 'ecpg_execute': execute.c:1277: error: 'ECPGst_execute' undeclared (first use in this function) execute.c:1277: error: (Each undeclared identifier is reported only once execute.c:1277: error: for each function it appears in.) execute.c: At top level: execute.c:1428: error: conflicting types for 'ECPGdo' /data/odysseus/afsudev/usr/include/ecpglib.h:47: error: previous declaration of 'ECPGdo' was here execute.c: In function 'ECPGdo': execute.c:1436: error: variable 'statement_type' has initializer but incomplete type execute.c:1436: error: conversion to incomplete type execute.c:1436: error: storage size of 'statement_type' isn't known execute.c:1490: error: 'ECPGst_prepnormal' undeclared (first use in this function) execute.c:1500: error: 'ECPGst_execute' undeclared (first use in this function) execute.c:1436: warning: unused variable 'statement_type' make[4]: *** [execute.o] Error 1 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
Re: [PATCHES] [BUGS] BUG #3973: pg_dump using inherited tables do not always restore
> It seems much more restrictive than necessary, plus it does nothing > for the check-constraint case. My recollection of the previous > discussion about how to fix this was that we needed to add an inhcount > column to pg_constraint, and add entries for not-null constraints (at > least inherited ones) to pg_constraint so that they'd be able to have > inhcount fields. The latter would also allow us to attach names to > not-null constraints, which I think is required by spec but we've never > supported. > > regards, tom lane > Ok I found some time to look at what would be involved in that... Seems doable. Ill see what I can whip up in the next month. (Im time pressed, who isn't though) Ill just post whatever i come up with (if and when) to psql-patches. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
Re: [BUGS] pg_dump produces invalid SQL for "group by cast(null as numeric)"
FYI, this was fixed in 8.3.0; not sure you got the report of the fix. --- Martin Pitt wrote: -- Start of PGP signed section. > Hi PostgreSQL developers, > > in [1], a user reported a failure of pg_dump: > > snip -- > 1. Create an empty database. > > 2. Connect to the database and create these views: > > create view foo as select 3; > create view bar as select count(*) from foo group by cast(null as numeric); > > 3. pg_dump the database to a text file. The file contains > >'CREATE VIEW bar AS >SELECT count(*) AS count FROM foo GROUP BY 2;' > > 4. Drop view bar from the database. > > 5. Run the CREATE VIEW bar..; statement from the text file. > > 6. The statement fails with > >'ERROR: GROUP BY position 2 is not in select list' > snip -- > > I verified that this is still an issue on 8.3 CVS head. > > However, I admit that I'm not sure why "group by cast(null as > numeric)" is useful. However, it actually works in the DB and fails in > pg_dump, so either it is valid and should be handled by pg_dump, or it > is invalid and should not be accepted in the first place. > > Thank you! > > Martin > > [1] https://bugs.launchpad.net/bugs/177382 > > -- > Martin Pitthttp://www.piware.de > Ubuntu Developer http://www.ubuntu.com > Debian Developer http://www.debian.org -- End of PGP section, PGP failed! -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
Re: [BUGS] BUG #3833: Index remains when table is dropped
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Mark Kirkwood wrote: > I encountered this bug recently - and thought I'd have a try at seeing > what might fix it. > > Taking an exclusive lock on the to-be-dropped table immediately (i.e in > RemoveRel) seems to be enough to prevent the drop starting while an > index is being created in another session. So it "fixes" the issue - > possible objections that I can think of are: > > 1/ Not a general solution to multi session dependent drop/create of > objects other than tables (unless we do 2/) > 2/ Using this approach in all object dropping code may result in > deadlocks (but is this worse than dangling/mangled objects?) > > Now, I'm conscious that there could be other show stopper reasons for > *not* doing this that I have not thought of, but figured I'd post in > case the idea was useful. Thoughts? > > Cheers > > Mark > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate >subscribe-nomail command to [EMAIL PROTECTED] so that your >message can get through to the mailing list cleanly -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
Re: [BUGS] BUG #3839: LDAP authentification and password with "space"-symbol
Has this bug been verified or fixed? --- Bronnikov Vladimir wrote: > > The following bug has been logged online: > > Bug reference: 3839 > Logged by: Bronnikov Vladimir > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.2.5 > Operating system: Windows 2000 SP4 > Description:LDAP authentification and password with "space"-symbol > Details: > > I set up my PostgreeSQL server to authenticate with LDAP. But when I connect > to my application with password containing "space" symbol, I receive > following error message: "LDAP authentication failed for user...". Other > users (with password not containg "spaces") login successfull. > > ---(end of broadcast)--- > TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
Re: [BUGS] BUG #4016: Build fails in ecpglib on file extern.h
"Samuel Gilbert" <[EMAIL PROTECTED]> writes: > I tried to build 8.3.0 on Debian GNU/Linux Etch x86_64 with the following > configure options : > ./configure --prefix=/data/aq_ops/software/x86_64 --enable-thread-safety > --with-pgport=5433 --with-tcl --with-perl --with-python --with-pam > --with-ldap --with-openssl --with-libxml --with-libxslt You seem to have omitted some relevant information, because there's a bunch of stuff in the compile command that did not come from these configure options: > gcc -march=opteron -mfpmath=sse -fomit-frame-pointer -Wall -pipe -O2 > -I/data/odysseus/afsudev/usr/include In particular I'm betting this -I switch is injecting some old-version ecpg include files into the situation. Possibly you are building with CPPFLAGS and/or CFLAGS already set in your environment? That's sometimes useful but you have to be mighty careful what you inject into builds that way. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
Re: [BUGS] BUG #3774: create table like including index doesn't update pg_constraints with primary key
Tom, did your commit to clean up LIKE ... INCLUDING INDEXES fix
this?
> ---
>
> guillaume (ioguix) de Rorthais wrote:
> >
> > The following bug has been logged online:
> >
> > Bug reference: 3774
> > Logged by: guillaume (ioguix) de Rorthais
> > Email address: [EMAIL PROTECTED]
> > PostgreSQL version: 8.3 beta3
> > Operating system: mac os x 10.4.10
> > Description:create table like including index doesn't update
> > pg_constraints with primary key
> > Details:
> >
> > When creating a table using the "create table ... (like ... inluding
> > indexes...)" syntaxe, pg_catalog.pg_constraint is not updated with the PK
> > constraints which actually is setted in pg_index.
> >
> > Here is my test script :
> >
> > pagila=# --the original table
> >
> > \d city
> >
> >
> >
> > Table "public.city"
> >Column|Type | Modifiers
> >
> > -+-+
> >
> > city_id | integer | not null default
> > nextval('city_city_id_seq'::regclass)
> > city| character varying(50) | not null
> > country_id | smallint| not null
> > last_update | timestamp without time zone | not null default now()
> > Indexes:
> > "city_pkey" PRIMARY KEY, btree (city_id)
> > "idx_fk_country_id" btree (country_id)
> > Foreign-key constraints:
> > "city_country_id_fkey" FOREIGN KEY (country_id) REFERENCES
> > country(country_id) ON UPDATE CASCADE ON DELETE RESTRICT
> > Triggers:
> > last_updated BEFORE UPDATE ON city FOR EACH ROW EXECUTE PROCEDURE
> > last_updated()
> >
> > pagila=# -- its pk constraint in pg_constraint
> >
> > SELECT relname,
> > conname, contype
> >
> > FROM pg_class cl
> >
> >
> >JOIN pg_constraint co ON (cl.oid=co.conrelid)
> >
> >
> > JOIN pg_namespace n ON (cl.relnamespace=n.oid)
> >
> > WHERE
> > cl.relname='city' AND n.nspname='public' AND contype='p';
> > relname | conname | contype
> > -+---+-
> > city| city_pkey | p
> > (1 row)
> >
> > pagila=# -- create the new table citylike like city
> >
> > CREATE TABLE
> > citylike (LIKE city INCLUDING INDEXES INCLUDING DEFAULTS);
> > CREATE TABLE
> > pagila=# --the citylike table
> >
> > \d citylike
> > Table "public.citylike"
> >Column|Type | Modifiers
> >
> > -+-+
> >
> > city_id | integer | not null default
> > nextval('city_city_id_seq'::regclass)
> > city| character varying(50) | not null
> > country_id | smallint| not null
> > last_update | timestamp without time zone | not null default now()
> > Indexes:
> > "citylike_pkey" PRIMARY KEY, btree (city_id)
> > "citylike_country_id_key" btree (country_id)
> >
> > pagila=# -- citylike constraints'
> > pagila=# SELECT relname, conname, contype
> >
Re: [BUGS] BUG #3774: create table like including index doesn't update pg_constraints with primary key
Bruce Momjian <[EMAIL PROTECTED]> writes: > Tom, did your commit to clean up LIKE ... INCLUDING INDEXES fix > this? Yes, see 2007-12-01 commit. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.org&extra=pgsql-bugs
Re: [BUGS] Problem identifying constraints which should not be inherited
Added to TODO: > o Require all CHECK constraints to be inherited > > http://archives.postgresql.org/pgsql-bugs/2007-04/msg00026.php --- Tom Lane wrote: > "Chris Fischer" <[EMAIL PROTECTED]> writes: > > alter table only t1 add constraint ck_col1 check (number <> 0); > > The bug here is that we allow that. Continuing your example, > > regression=# insert into t2 values(0); > INSERT 0 1 > regression=# select * from t1; > col1 > -- > 0 > (1 row) > > which sure looks to me like a violation of the principle of least > surprise. > > This has come up before and I think the consensus was to disallow > non-inherited check constraints; not sure why it hasn't been done yet. > > regards, tom lane > > ---(end of broadcast)--- > TIP 3: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faq -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
