Re: Extensions, this time with a patch

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extensions, this time with a patch
Date: 2010-10-19 13:47:31
Message-ID: AANLkTikrTtvT7m4x2OdDcikhLhOCazsGmXoBHcM7i-vw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Oct 19, 2010 at 9:07 AM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I don't see why.  I think the real action item here is to remove =>
>> from hstore.
>
> As input, consider that lots of extensions will create types that are
> only a shell at the moment of the CREATE TYPE, and for each of those
> types you will see the (potentially > 1000 lines long) whole SQL script
> dumped on the screen.
>
> In the following script, I've filtered out the scripts, but it's written
> out for each NOTICE message that you see:
>
> dim ~/dev/PostgreSQL/postgresql-extension psql -c "create extension citext;" 2>&1 | egrep 'NOTICE|ERROR'
> NOTICE:  Installing extension 'citext' from '/Users/dim/pgsql/exts/share/contrib/citext.sql', with user data
> NOTICE:  return type citext is only a shell
> NOTICE:  argument type citext is only a shell
> NOTICE:  return type citext is only a shell
> NOTICE:  argument type citext is only a shell

Well, perhaps it's reasonable to suppress NOTICE messages then. That
particular message could perhaps be quieted, but we probably don't
want to do that with every NOTICE that might occur (e.g. those that
you might get on table creation for sequences, indices, etc.).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2010-10-19 14:05:55 Re: WIP: extensible enums
Previous Message Boszormenyi Zoltan 2010-10-19 13:32:12 Re: plan time of MASSIVE partitioning ...