On 9 Oct 2012, at 6:54pm, Adam DeVita wrote:
> The why seems to be something about the necessity of rewriting the
> table, which is 'slow'. I expect that users accept that Alter table
> can be expensive.Is there more to it? Some sort of ACID breakdown?
There are problems with ALTER TABLE,
e, Oct 9, 2012 at 9:00 AM, wrote:
>
>> Message: 11
>> Date: Mon, 08 Oct 2012 21:57:21 +0200
>> From: Yves Goergen
>> To: General Discussion of SQLite Database
>> Subject: [sqlite] Why can't SQLite drop columns?
>> Message-ID: <50733021.8020...@unclassifi
.lcsql.com.
On Tue, Oct 9, 2012 at 9:00 AM, wrote:
> Message: 11
> Date: Mon, 08 Oct 2012 21:57:21 +0200
> From: Yves Goergen
> To: General Discussion of SQLite Database
> Subject: [sqlite] Why can't SQLite drop columns?
> Message-ID: <50733021.8020...@unclassified.de&
On 10/8/12, Petite Abeille wrote:
> How do they deal with constraints? triggers? indexes? others?
> If this was as straightforward as a 'create table bar as select a, b, c from
> foo; drop table foo; alter table bar rename to foo;', we would most likely
> not having this conversation :)
I'm sorry
You can do it, but you need to parse the existing table schema.
1. Get the existing schema for the table, along with associated triggers and
indexes: select group_concat(SQL, x'0A' || ';' || x'0A') from SQLite_Master
where tbl_name = 'My Table'.
2. Edit the create table schema to remove the col
Jay Kreibich wrote:
On Oct 8, 2012, at 3:36 PM, Darren Duncan wrote:
Of course, if that is done, then in order to have predictable performance we'd also want
to add some other statement one can invoke when they want to reclaim disk space later,
which actually goes and rewrites the table, rath
On Oct 8, 2012, at 10:47 PM, gregorinator wrote:
> (they do it by copying the table, but it's transparent to
> you).
How do they deal with constraints? triggers? indexes? others?
If this was as straightforward as a 'create table bar as select a, b, c from
foo; drop table foo; alter table ba
Some freeware SQLite tools, such as SQLiteStudio, allow you to drop
columns (they do it by copying the table, but it's transparent to
you). If you don't need to drop the column programmatically, as part
of a bigger automated process, it works and you don't have to code
anything.
gs
__
On Oct 8, 2012, at 10:36 PM, Darren Duncan wrote:
> Petite Abeille wrote:
>> On Oct 8, 2012, at 10:12 PM, Richard Hipp wrote:
>>> ALTER TABLE DROP COLUMN requires writing every row of the table.
>> Could be a 'logical delete' instead. In other words, a dictionary operation
>> instead of a data
On 08.10.2012 22:12 CE(S)T, Richard Hipp wrote:
> The only ALTER TABLE functions that SQLite supports are those that can be
> accomplished without having to rewrite the entire table.
Oh, and what about the VACUUM command? That certainly needs to recreate
just about everything, and yet it's here. (
On 08.10.2012 22:12 CE(S)T, Richard Hipp wrote:
> ALTER TABLE DROP COLUMN requires writing every row of the table.
Actually, I wouldn't care what the engine needs to do to get the job
done. If it's documented that a certain command requires more time, it
would be perfectly fine. SELECT queries als
On Oct 8, 2012, at 10:12 PM, Richard Hipp wrote:
> the only ALTER TABLE functions supported are those that can be
> done in O(1) time.
Out of curiosity, does 'add column not null default' modify the data or just
the table definition?
For example:
create table foo( x, y );
insert into foo va
On Oct 8, 2012, at 3:36 PM, Darren Duncan wrote:
> Petite Abeille wrote:
>> On Oct 8, 2012, at 10:12 PM, Richard Hipp wrote:
>>> ALTER TABLE DROP COLUMN requires writing every row of the table.
>> Could be a 'logical delete' instead. In other words, a dictionary operation
>> instead of a data
Petite Abeille wrote:
On Oct 8, 2012, at 10:12 PM, Richard Hipp wrote:
ALTER TABLE DROP COLUMN requires writing every row of the table.
Could be a 'logical delete' instead. In other words, a dictionary operation
instead of a data one.
http://www.oracle-base.com/articles/8i/dropping-columns
On Oct 8, 2012, at 10:12 PM, Richard Hipp wrote:
> ALTER TABLE DROP COLUMN requires writing every row of the table.
Could be a 'logical delete' instead. In other words, a dictionary operation
instead of a data one.
http://www.oracle-base.com/articles/8i/dropping-columns.php#LogicalDelete
___
On Mon, Oct 8, 2012 at 3:57 PM, Yves Goergen wrote:
>
> Why does SQLite still not support dropping columns
> through SQL after all these years?
>
The only ALTER TABLE functions that SQLite supports are those that can be
accomplished without having to rewrite the entire table. Or, to put it
anoth
Hello,
I know that SQLite doesn't support ALTER TABLE DROP COLUMN, unlike
probably every other SQL database system. But every time I come across
this, I feel the pain of having to write huge amounts of code to
automatically remove single columns in a table. When doing that in code,
it's usually wo
17 matches
Mail list logo