Re: full featured alter table?

From: "Jay O'Connor" <joconnor(at)cybermesa(dot)com>
To: weigelt(at)metux(dot)de, pgsql-general(at)postgresql(dot)org
Subject: Re: full featured alter table?
Date: 2003-06-14 21:18:43
Message-ID: 3.0.1.32.20030614151843.00885770@cybermesa.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

At 10:32 PM 06/14/2003 +0200, weigelt(at)metux(dot)de wrote:
>On Sat, Jun 14, 2003 at 10:18:30PM +0200, Sven K?hler wrote:
>
><snip>
>> what are you talking about? it is not _my_ frontend!
>> we're talking "frontends" about pgAdmin, phpPgAdmin etc.
>yes. why couldnt they simply use an extra table for this - just
>like pgaccess does for storing its config ?
>user-side column odering is frontend stuff.
>it dont like the idea that SELECT * doesnt use the physical order
>(from pg_attribute - which you also can see w/ \d in the pgsql frontend)

I tend to agree that column ordering does not belong in that database.
Simply because I find it hard to believe that yuo would only and always
want "SELECT *" to come across to the client in a specific order. Context
indicates what the column order needs to be.

One other wrinkle is what to do wth "SELECT * from tablea, tableb" Do you
use all of tablea and then all of tableb? Or interleave with (first from
tablea, first from tableb, second from tablea, second from tableb...)

Besides I usually load a record in a dictionary structure in my client
language (python or smalltalk) which means a) the order is based on the
hash ordering of the dictionary structure anyway and b) I'm doing things by
name, not position.

Take care,
Jay

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Nigel J. Andrews 2003-06-14 22:36:48 Re: Growing Database Size
Previous Message Robert C. Paulsen Jr. 2003-06-14 21:16:34 crypt vs password in pg_hba.conf