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
, 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
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
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.
>
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
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
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
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
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
