Re: [HACKERS] [OT] why not keeping the original column name in catalog after a drop?

2013-11-13 Thread Luca Ferrari
On Wed, Nov 13, 2013 at 9:00 AM, Andres Freund and...@2ndquadrant.com wrote: The old name might not fit there, attribute names have a relatively low maximum length (64 by default), so we cannot always fit the entire old name there. Thanks, I was guessing this. Also, think about: CREATE

[HACKERS] [OT] why not keeping the original column name in catalog after a drop?

2013-11-12 Thread Luca Ferrari
Hi all, when you drop a column on a table the pg_attribute is updated and the name of the column is changed with an almost fixed identifier that reports only the original column position: /* * Change the column name to something that isn't likely to conflict */ snprintf(newattname,

Re: [HACKERS] 9.0.3 SIGFAULT on FreeBSD with dtrace

2011-04-05 Thread Luca Ferrari
On Saturday, April 02, 2011 09:12:32 PM Tom Lane's cat walking on the keyboard wrote: It's possible that we need to adjust PG's dtrace code to support the FreeBSD implementation, but if so we'd need advice from an expert on what needs to be changed. Thanks. In the meantime I attached a

[HACKERS] 9.0.3 SIGFAULT on FreeBSD with dtrace

2011-03-30 Thread Luca Ferrari
HI all, I'm trying to compile PostgreSQL 9.0.3 on FreeBSD 8.1-stable, and I can make it working if I compile without dtrace. However when I compile with --enable- dtrace I'm unable to use the cluster and even initdb. In particular initdb claims that: fgets failure: No such file or directory The

[HACKERS] RelOptInfo-reltargetlist

2007-08-20 Thread Luca Ferrari
Hi all, apologize if this is a trivial question but I'd like to understand what values are stored in the RelOptInfo-reltargetlist or, better, how I can check such values in the information schema to understand what they refer to. I've tried to look in the pg_attribute table but I was not able