Thread: cannot remove column + no error msg
Hi all, sorry for the clutter, but cannot find a good answer to this problem in the mailinglist archives: If I execute either of both commands (I run postgresql 8.1.4 on Ubuntu GNU/linux): # ALTER TABLE table_name DELETE COLUMN column # ALTER TABLE table_name DROP COLUMN column nothing happens... if I do # \d table_name, all columns are still nicely present, like nothing happened at all. In the pgsql-docs, I found that columns are not physically removed but made only unvisible to SQL commands. However, I DO want to physically remove those columns, since they are empty anyway. But apparently no way how to do it. Does anybody knows a way how to proceed? Second question is related to that. If I type any bogus (e.g. "sflkjdslkfj") onto the psql commandline, PostgreSQL remains silent. This is nice in some cases, but is there a way to let it do some error checking on the bogus I type? I am not used to commandlines that just swallow text and don't warn for any errors, giving me the idea that the it is apparently correct. Anybody any idea to change some configuration parameters? thanks in advance, Bram
am Mon, dem 11.12.2006, um 16:11:24 +0100 mailte Bram Kuijper folgendes:
> Hi all,
>
> sorry for the clutter, but cannot find a good answer to this problem in
> the mailinglist archives:
>
> If I execute either of both commands (I run postgresql 8.1.4 on Ubuntu
> GNU/linux):
>
> # ALTER TABLE table_name DELETE COLUMN column
> # ALTER TABLE table_name DROP COLUMN column
You are in the psql-tool?
The first syntax is wrong, the latter are okay, but you need a ';' on
the linend.
>
> nothing happens... if I do
>
> # \d table_name,
test=# \d foobar
Table "public.foobar"
Column | Type | Modifiers
--------+---------+-----------
id | integer |
a | integer |
b | integer |
c | integer |
test=# alter table foobar drop column c;
ALTER TABLE
test=*# \d foobar
Table "public.foobar"
Column | Type | Modifiers
--------+---------+-----------
id | integer |
a | integer |
b | integer |
Andreas
--
Andreas Kretschmer
Kontakt: Heynitz: 035242/47215, D1: 0160/7141639 (mehr: -> Header)
GnuPG-ID: 0x3FFF606C, privat 0x7F4584DA http://wwwkeys.de.pgp.net
On Mon, December 11, 2006 10:11 am, Bram Kuijper said: > Second question is related to that. If I type any bogus (e.g. > "sflkjdslkfj") onto the psql commandline, PostgreSQL remains silent. > This is nice in some cases, but is there a way to let it do some error > checking on the bogus I type? I am not used to commandlines that just > swallow text and don't warn for any errors, giving me the idea that the > it is apparently correct. Anybody any idea to change some configuration > parameters? More related than you think, probably... An SQL statement is terminated by a semicolon, and nothing else. Until the statement is ended, there is no error. I bet if you type bogus characters into psql and finish with a ; it will give you an error. Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---------------------------------------------------------------
"Daniel T. Staal" <DStaal@usa.net> writes:
> On Mon, December 11, 2006 10:11 am, Bram Kuijper said:
>> Second question is related to that. If I type any bogus (e.g.
>> "sflkjdslkfj") onto the psql commandline, PostgreSQL remains silent.
> More related than you think, probably...
> An SQL statement is terminated by a semicolon, and nothing else. Until
> the statement is ended, there is no error. I bet if you type bogus
> characters into psql and finish with a ; it will give you an error.
Also, backslash commands take a different path --- it's possible to
execute \d for example while psql still thinks it's accumulating a
multi-line SQL command to send when it finally sees a semicolon.
regards, tom lane