Re: Add new column

Once ago I had a similar problem.
The developers team requested about creating a new column, and the placement
was important. Thus, changing the app code was too expensive. A bad habit,
was my reply,
but as expected I had to found a solution for the problem.
Create a view and rename the table, it will add a overhead, but it sort
my problem.
(...and they didn't notice ;) )
Regards,
Guido

On 7/20/05, Goulet, Dick <DGoulet(at)vicr(dot)com> wrote:
>
> Then drop and rebuild the table. Otherwise add it onto the end, which I
> believe is ANSI SQL expected behavior and forget about it. Where the
> column is in the table is less important than where you place it in the
> select statement. The only other time I can see column placement as
> being important is if it's part of the primary key, but even then I've
> had no problems with adding to the end of the table.
>
> -----Original Message-----
> From: pgsql-admin-owner(at)postgresql(dot)org
> [mailto:pgsql-admin-owner(at)postgresql(dot)org] On Behalf Of Rafal Kedziorski
> Sent: Wednesday, July 20, 2005 4:49 AM
> To: pgsql-admin(at)postgresql(dot)org
> Subject: [ADMIN] Add new column
>
> Hi,
>
> I wan't add new column to this table:
>
> CREATE SEQUENCE abo_product_2_user_seq;
>
> CREATE TABLE abo_product_2_user (
> abo_product_2_user_id BIGINT NOT NULL DEFAULT
> NEXTVAL('abo_product_2_user_seq'),
> abo_product_id SMALLINT NOT NULL,
> user_id BIGINT NOT NULL,
> valid_from TIMESTAMP NOT NULL,
> valid_to TIMESTAMP,
> debit_entry VARCHAR(12) NOT NULL,
> --
> PRIMARY KEY (abo_product_2_user_id),
> --INDEX (abo_product_id),
> --INDEX (user_id),
> FOREIGN KEY (abo_product_id)
> REFERENCES abo_product (abo_product_id),
> FOREIGN KEY (user_id)
> REFERENCES users (user_id)
> );
>
> But PostgreSQL 8.0.3 adds the new column at the end. I want add this
> new column between user_id and valid_from.
>
>
> Best Regards,
> Rafal
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>

--
"Adopting the position that you are smarter than an automatic
optimization algorithm is generally a good way to achieve less
performance, not more" - Tom Lane.