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
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 |