Re: [BUGS] Errors on CREATE TABLE IF NOT EXISTS

suggestion. I will surely follow the advice as soon as the load starts to grow. For now catching the "table not found" exception within the insert trigger and creating the table on the fly seems a good balance between performance and ease of use. Cheers -- Matteo Beccati Development

Re: [BUGS] Errors on CREATE TABLE IF NOT EXISTS

, but I thought it was better to report that anyway, just in case. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs

[BUGS] Errors on CREATE TABLE IF NOT EXISTS

x" DETAIL: Key (typname, typnamespace)=(_foo, 2200) already exists. ERROR: duplicate key value violates unique constraint "pg_type_typname_nsp_index" DETAIL: Key (typname, typnamespace)=(_foo, 2200) already exists. DROP TABLE I'm not sure if the two failures are relate

[BUGS] corrupted table postgresql 8.3

se other objects depend on it HINT: Use DROP ... CASCADE to drop the dependent objects too. I'll stop here to describe further detail... can you suppose what is happened please? After that can we discuss how to cleanup the situation...;) Thanks a lot! Matteo -- Sent via pgsql-bugs mai

Re: [BUGS] BUG #6416: Expression index not used with UNION ALL queries

On 29/01/2012 22:33, Tom Lane wrote: > Matteo Beccati writes: >>> I've just noticed that an expression index I've created was not used with a >>> view contiaining a UNION ALL. Switching to UNION or querying the table >>> directly works as expected. >

Re: [BUGS] BUG #6416: Expression index not used with UNION ALL queries

On 29/01/2012 16:06, p...@beccati.com wrote: > The following bug has been logged on the website: > > Bug reference: 6416 > Logged by: Matteo Beccati > Email address: p...@beccati.com > PostgreSQL version: 9.1.2 > Operating system: Debian

Re: [BUGS] Postgresql 9.1.2 - abnormal memory usage

ct fix is to revert these functions to the former >> behavior, ie they should be using the PP macros not the unpacking ones. > > Agreed, there's no need to unpack here. Fixed, thanks for the report! Just to clarify, am I correct assuming that the issue does not affect tables whic

Re: [BUGS] BUG #5255: COUNT(*) returns wrong result with LEFT JOIN

Il 25/12/2009 18:13, Tom Lane ha scritto: I wrote: I guess we missed something about when it's safe to do this optimization. I've applied the attached patch to fix this. Thanks. Everything's working fine now! Merry Xmas -- Matteo Beccati Development & Consulting - htt

[BUGS] BUG #5255: COUNT(*) returns wrong result with LEFT JOIN

The following bug has been logged online: Bug reference: 5255 Logged by: Matteo Beccati Email address: p...@beccati.com PostgreSQL version: 8.5alpha3 Operating system: NetBSD 5.0.1 Description:COUNT(*) returns wrong result with LEFT JOIN Details: Discovered this

Re: [HACKERS] Re: [BUGS] BUG #4689: Expanding the length of a VARCHAR column should not induce a table rewrite

ll table rewrite even though the underlying type definition were exactly the same (i.e. varchar(64)). I can live with it, but I suppose this fix might be related to the varlen one. Cheers -- Matteo Beccati OpenX - http://www.openx.org -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql

[BUGS] vacuum is not sufficient?

some ideas? Thanks in advance! Matteo ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

[BUGS] Drop function from a batch file error

the function the operation has happened Tested on debian potato (pg 7.1) and on slackware (your actual tarball on intel processor) If you can try it good else send me a mail and when I have time I will send an example. Regards, and tnx for your job. Matteo Nastasi. -- Linux -