Re: Adding \ev view editor?

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Adding \ev view editor?
Date: 2009-09-02 07:41:04
Message-ID: m263c1oktr.fsf@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:

> On tis, 2009-09-01 at 11:41 -0700, Josh Berkus wrote:
>> Opinions? Other objects which could take \e?
>
> All of them.

Well, I'd vote against \e table. Are you going to propose the CREATE
TABLE statement and have magics to produce the ALTER TABLE that would
resort? I hope not, because in some cases I fail to see how you'd do it
(CREATE TABLE AS SELECT ... comes to mind, and CREATE TABLE ... (LIKE
...) INHERITS ...; too, let alone where to put the column and table
constraints: separate commands or embedded ones?).

So you'd propose ALTER TABLE ... and nothing more, and I don't see any
gain in that, but maybe it's just me.

Editing an index is interesting too, do you generate a DROP INDEX then
the new CREATE INDEX, do you add a CREATE INDEX CONCURRENTLY somewhere
in the mix, etc...

More generally, as said upthread, \e should certainly only be available
for objects we can CREATE OR REPLACE...

Regards,
--
dim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sergey Konoplev 2009-09-02 11:18:31 Feature request: DEFAULT as input value of function argument
Previous Message KaiGai Kohei 2009-09-02 07:25:14 Re: community decision-making & 8.5