Good day,
See the sequence below, Postgresql 9.6.5 on Debian using the postgresql
repository.
Question: Is this expected behaviour?
postgres@tracsdbhvt01:~$ cat test-serial.sql
create database test;
\c test
create table test_serial ( teststring varchar(5));
alter table test_serial add colum
On 11-10-2016 15:59, Vitaly Burovoy wrote:
On 10/11/16, Condor wrote:
Hello,
today I need to alter one of our biggest tables to add two new columns
with default value 0.
Server version: PostgreSQL 9.5.4 on x86_64-slackware-linux-gnu,
compiled
by x86_64-slackware-linux-gcc (GCC) 5.3.0, 64-bi
On 10/11/16, Condor wrote:
>
> Hello,
>
> today I need to alter one of our biggest tables to add two new columns
> with default value 0.
> Server version: PostgreSQL 9.5.4 on x86_64-slackware-linux-gnu, compiled
> by x86_64-slackware-linux-gcc (GCC) 5.3.0, 64-bit
>
> when I do: ALTER TABLE stocks
Hello,
today I need to alter one of our biggest tables to add two new columns
with default value 0.
Server version: PostgreSQL 9.5.4 on x86_64-slackware-linux-gnu, compiled
by x86_64-slackware-linux-gcc (GCC) 5.3.0, 64-bit
when I do: ALTER TABLE stocks ADD COLUMN promo INTEGER DEFAULT 0;
lo
On 06/06/16 10:55, Rick Widmer wrote:
> Do I need to vacuum after an alter table command?
If the specific command you do rewrites the table, you absolutely should
vacuum in order to restore the visibility map. Otherwise, it not necessary.
> Does it matter if there is a default or if we accept NU
Do I need to vacuum after an alter table command?
Does it matter if there is a default or if we accept NULLs for the new
field?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 01/07/2015 11:57 PM, John Casey wrote:
> I have been thinking about an alternate means of implementing global
> sequences that I feel would simplify things.
>
> Rather than chunking out blocks, set an increment value for each sequence
> equal to the number of nodes in the "cluster". Each nod
I have been thinking about an alternate means of implementing global sequences
that I feel would simplify things.
Rather than chunking out blocks, set an increment value for each sequence equal
to the number of nodes in the "cluster". Each node has an offset. So, if you
have 10 nodes, mode 1 h
On 01/04/2015 12:33 AM, John Casey wrote:
> While attempting to alter a table to add a global sequence as a primary
> key using the following commands:
>
> CREATE SEQUENCE my_table_id_seq USING bdr;
>
> ALTER TABLE my_table
>
> ADD COLUMN id integer PRIMARY KEY NOT NULL DEFAULT
> nextval('my_tab
While attempting to alter a table to add a global sequence as a primary key
using the following commands:
CREATE SEQUENCE my_table_id_seq USING bdr;
ALTER TABLE my_table
ADD COLUMN id integer PRIMARY KEY NOT NULL DEFAULT
nextval('my_table_id_seq'::regclass);
I started to notice some issue
Hi,
I want to add a new column named sell_time to a table which already has
a boolean field named is_sold. Then I want to create a new check constraint:
ALTER TABLE ...
CHECK(is_sold AND sell_time IS NOT NULL OR
NOT is_sold AND sell_time IS NULL)
NOT VALID;
The constraint is added as NOT V
Tom Lane-2 wrote
>> Why don't we rewrite tuples with their existing xid in such cases?
>> The current state of affairs seem to me to be a pretty clear bug.
>
> No, it isn't --- the tuple is being modified by the ALTER command.
>
> regards, tom lane
I'm not quite sure what
Kevin Grittner wrote:
> Tom Lane wrote:
>> Kevin Grittner writes:
>>> Why don't we rewrite tuples with their existing xid in such
>>> cases? The current state of affairs seem to me to be a pretty
>>> clear bug.
>>
>> No, it isn't --- the tuple is being modified by the ALTER
>> command.
>
> If a
Tom Lane wrote:
> Kevin Grittner writes:
>> Why don't we rewrite tuples with their existing xid in such
>> cases? The current state of affairs seem to me to be a pretty
>> clear bug.
>
> No, it isn't --- the tuple is being modified by the ALTER
> command.
If a REPEATABLE READ or SERIALIZABLE tr
Kevin Grittner writes:
> Why don't we rewrite tuples with their existing xid in such cases?
> The current state of affairs seem to me to be a pretty clear bug.
No, it isn't --- the tuple is being modified by the ALTER command.
regards, tom lane
--
Sent via pgsql-gener
Kevin Grittner-5 wrote
>> [ Examples shows that both SERIALIZABLE and REPEATABLE READ
>> transactions could see an empty table which was not empty as of
>> the point the snapshot was taken. For that matter, it was not
>> empty at any later point, either. ]
>
> Why don't we rewrite tuples with the
DT wrote:
> I'm reading code of ALTER TABLE, and I found when target table
> needs rewrite, tuple inserted into new heap uses current
> transaction's xid as xmin.
That sure sounds wrong to me.
> Does this behavior satisfy serializable isolation? I wrote some
> test cases:
>
> [ Examples shows
DT wrote
> Hi,
>
> I'm reading code of ALTER TABLE, and I found when target table needs
> rewrite, tuple inserted into new heap uses current transaction's xid as
> xmin. Does this behavior satisfy serializable isolation? I wrote some test
> cases:
> CREATE TABLE t1(a INT);CREATE TABLE t2(a INT);
Hi,
I'm reading code of ALTER TABLE, and I found when target table needs rewrite,
tuple inserted into new heap uses current transaction's xid as xmin. Does this
behavior satisfy serializable isolation? I wrote some test cases:
CREATE TABLE t1(a INT);CREATE TABLE t2(a INT);INSERT INTO t1 VALUES
On Tue, Jul 30, 2013 at 10:34 AM, bricklen wrote:
> Sorry bricklen, I've killed all idle connections with "kill -9 ",
>
>> then I was able to execute the alter table.
>>
>
> No problem.
>
btw, I meant 'no need to apologize that the queries were gone', not that I
recommend "kill -9" (I don't!)
Leonardo M. Ramé escribió:
> Sorry bricklen, I've killed all idle connections with "kill -9 ",
> then I was able to execute the alter table.
I don't think that was such a great idea. Once you killed the first
one, postmaster terminated all other server processes, run recovery, and
restarted serv
On Tue, Jul 30, 2013 at 10:29 AM, Leonardo M. Ramé wrote:
> > > select pg_cancel_backend(pid) from pg_stat_activity where pid <>
> > > pg_backend_pid();
>
As Giuseppe mentioned, if you need to kill not just the queries, but the
connection as well, you could use:
select pg_terminate_backend(pid)
On 2013-07-30 10:26:39 -0700, bricklen wrote:
> On Tue, Jul 30, 2013 at 10:07 AM, Leonardo M. Ramé wrote:
>
> >
> > select pg_cancel_backend(pid) from pg_stat_activity where pid <>
> > pg_backend_pid();
> >
> > And it returned this:
> >
> > pg_cancel_backend
> > ---
> > t
> > t
>
On Tue, Jul 30, 2013 at 10:07 AM, Leonardo M. Ramé wrote:
>
> select pg_cancel_backend(pid) from pg_stat_activity where pid <>
> pg_backend_pid();
>
> And it returned this:
>
> pg_cancel_backend
> ---
> t
> t
> (2 rows)
>
> But when I execute my update table command, it still nev
On 2013-07-30 17:56:16 +0200, Giuseppe Broccolo wrote:
> >How can I force disconnect all clients to let me alter that table?.
> >
> >Regards,
>
> There are two ways: the first|is based on pg_terminate_backend()
> function and 'pg_stat_activity' catalog |||to kill idle processes.
> So in a psql ses
How can I force disconnect all clients to let me alter that table?.
Regards,
There are two ways: the first|is based on pg_terminate_backend()
function and 'pg_stat_activity' catalog |||to kill idle processes.
So in a psql session type (tried on PostgreSQL 8.4):
==# SELECT procpid, (SELECT pg
On Tue, Jul 30, 2013 at 7:50 AM, Leonardo M. Ramé wrote:
> Hi, I need to do an alter table on a small table (~300 records), but it
> never ends. It may be because there are clients using that table.
>
> How can I force disconnect all clients to let me alter that table?.
>
If you are using Postgre
Hi, I need to do an alter table on a small table (~300 records), but it
never ends. It may be because there are clients using that table.
How can I force disconnect all clients to let me alter that table?.
Regards,
--
Leonardo M. Ramé
Medical IT - Griensu S.A.
Av. Colón 636 - Piso 8 Of. A
X5000E
CG writes:
> I want to add a column to a table, but there are update triggers that will
> fire that don't need to fire for this operation. So, I'd like to add the
> column with triggers off. Normally this operation would take 10 or so
> seconds, so locking the table for that amount of time is n
I'm using 8.4.1
I want to add a column to a table, but there are update triggers that will fire
that don't need to fire for this operation. So, I'd like to add the column with
triggers off. Normally this operation would take 10 or so seconds, so locking
the table for that amount of time is not
On 2010-11-24, Daniel Verite wrote:
> Fredric Fredricson wrote:
>
>> But if you change the column names in the second SELECT in the UNION this is
>> ignored:
>> # SELECT c1,c2 FROM (SELECT 1 AS c1, 2 AS c2 UNION SELECT 2 AS c3, 1 AS c4)
>> AS x;
>> c1 | c2
>> +
>> 1 | 2
>> 2 |
On Nov 24, 2010, at 9:42 AM, Derrick Rice wrote:
>
> Even if an example doesn't exist, you can at least imagine a scenario where
> an improvement to postgresql is made such that the column order is decided
> internally, rather than by table definition.
Not when SQL compatibility requires that t
Stuart McGraw writes:
> This is the first time I've ever looked at the 1000+ page spec and I
> haven't tried to chase down all the definitions so I don't pretend to
> be authoritative but it sure sounds to me (as your observation above
> implies) that SQL *does* have an explicit notion of column
On 11/24/2010 03:32 AM, Peter Bex wrote:
> On Wed, Nov 24, 2010 at 09:37:02AM +, Grzegorz Jaśkiewicz wrote:
>> just never use SELECT *, but always call columns by names. You'll
>> avoid having to depend on the order of columns, which is never
>> guaranteed, even if the table on disk is one orde
On Wed, Nov 24, 2010 at 4:43 AM, Thomas Kellerer wrote:
> Grzegorz Jaśkiewicz, 24.11.2010 10:37:
>
> just never use SELECT *, but always call columns by names. You'll
>> avoid having to depend on the order of columns, which is never
>> guaranteed, even if the table on disk is one order, the retu
Fredric Fredricson wrote:
> But if you change the column names in the second SELECT in the UNION this is
> ignored:
> # SELECT c1,c2 FROM (SELECT 1 AS c1, 2 AS c2 UNION SELECT 2 AS c3, 1 AS c4)
> AS x;
> c1 | c2
> +
> 1 | 2
> 2 | 1
> Apparently, in a UNION the column names
On 11/24/2010 12:31 PM, Florian Weimer wrote:
* Grzegorz Jaśkiewicz:
2010/11/24 Florian Weimer:
* Grzegorz Jaśkiewicz:
just never use SELECT *, but always call columns by names. You'll
avoid having to depend on the order of columns, which is never
guaranteed, even if the table on disk is one
* Grzegorz Jaśkiewicz:
> 2010/11/24 Florian Weimer :
>> * Grzegorz Jaśkiewicz:
>>
>>> just never use SELECT *, but always call columns by names. You'll
>>> avoid having to depend on the order of columns, which is never
>>> guaranteed, even if the table on disk is one order, the return columns
>>>
2010/11/24 Florian Weimer :
> * Grzegorz Jaśkiewicz:
>
>> just never use SELECT *, but always call columns by names. You'll
>> avoid having to depend on the order of columns, which is never
>> guaranteed, even if the table on disk is one order, the return columns
>> could be in some other.
>
> This
* Grzegorz Jaśkiewicz:
> just never use SELECT *, but always call columns by names. You'll
> avoid having to depend on the order of columns, which is never
> guaranteed, even if the table on disk is one order, the return columns
> could be in some other.
This can't be true because several SQL fea
On 2010-11-24 10.43, Thomas Kellerer wrote:
Grzegorz Jaśkiewicz, 24.11.2010 10:37:
just never use SELECT *, but always call columns by names. You'll
avoid having to depend on the order of columns, which is never
guaranteed, even if the table on disk is one order, the return columns
could be in
It is easy to create view based on SELECT which explicitly specifies
the columns names. IMO it is better to hide tables structures behind views
and work with them, since views are not materialized and it is easy to drop
and recreate or just add another view into the database. With this approach
you
On Wed, Nov 24, 2010 at 09:37:02AM +, Grzegorz Jaśkiewicz wrote:
> just never use SELECT *, but always call columns by names. You'll
> avoid having to depend on the order of columns, which is never
> guaranteed, even if the table on disk is one order, the return columns
> could be in some other
Grzegorz Jaśkiewicz, 24.11.2010 10:37:
just never use SELECT *, but always call columns by names. You'll
avoid having to depend on the order of columns, which is never
guaranteed, even if the table on disk is one order, the return columns
could be in some other.
I always try to convince people
just never use SELECT *, but always call columns by names. You'll
avoid having to depend on the order of columns, which is never
guaranteed, even if the table on disk is one order, the return columns
could be in some other.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To
Please note, that in cases when you can't do simple
dump - fix - restore (e.g. in production) you can always create
view(s) with ordinal positions of columns convenient for you.
2010/11/24 Dmitriy Igrishin
> Hey Alexander,
>
> Ordinal positions of columns can't be set manually by ALTER TABLE.
>
Alexander Farber, 24.11.2010 08:49:
Why do you want to do anything like that?
Easier to read... login, logout
I understand the "easier to read" part.
But what do you mean with "login, logout"?
Thomas
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to y
Easier to read... login, logout
On Wed, Nov 24, 2010 at 8:45 AM, Szymon Guz wrote:
> no
> Why do you want to do anything like that?
>
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-genera
Hey Alexander,
Ordinal positions of columns can't be set manually by ALTER TABLE.
2010/11/24 Alexander Farber
> Hello,
>
> is there a syntax to add a column not at the last place, but
> somewhere inbetween or do I have to dump/restore the table?
>
> For example if I'd like to add last_logout ri
Alexander Farber, 24.11.2010 08:42:
is there a syntax to add a column not at the last place
No, because the order of the column is irrelevant (just as there is no order on
the rows in a table)
Simply select them in the order you like to have.
Thomas
--
Sent via pgsql-general mailing list (p
On 24 November 2010 08:42, Alexander Farber wrote:
> Hello,
>
> is there a syntax to add a column not at the last place, but
> somewhere inbetween or do I have to dump/restore the table?
>
> For example if I'd like to add last_logout right after last_login:
>
> \d pref_users;
>Tab
Hello,
is there a syntax to add a column not at the last place, but
somewhere inbetween or do I have to dump/restore the table?
For example if I'd like to add last_logout right after last_login:
\d pref_users;
Table "public.pref_users"
Column |Type |
On Nov 17, 2010, at 12:42 PM, Richard Broersma wrote:
> ALTER TABLE foo
> DROP CONSTRAINT your_constraint,
> ADD CONSTRAINT your_constraint FOREIGN KEY ...
> ON UPDATE CASCADE ON DELETE RESTRICT;
Thanks. That worked.
-Aram
--
Sent via pgsql-general mailing list (pgsql-general@pos
Richard Broersma wrote:
> On Wed, Nov 17, 2010 at 8:43 AM, David Fetter wrote:
>
> > You can do it like this:
> >
> > BEGIN;
> > ALTER TABLE foo DROP CONSTRAINT your_constraint;
> > ALTER TABLE foo ADD FOREIGN KEY ...;
> > COMMIT;
>
> The nice thing about the ALTER TABLE statement is that you
On Wed, Nov 17, 2010 at 8:43 AM, David Fetter wrote:
> You can do it like this:
>
> BEGIN;
> ALTER TABLE foo DROP CONSTRAINT your_constraint;
> ALTER TABLE foo ADD FOREIGN KEY ...;
> COMMIT;
The nice thing about the ALTER TABLE statement is that you can do it
in one command:
ALTER TABLE foo
DR
On Wed, Nov 17, 2010 at 11:32:32AM -0500, Aram Fingal wrote:
> I have a table where I should have declared a foreign key with ON
> UPDATE CASCADE and didn't. Now I want to fix that. From the
> documentation on www.postgresql.org, about ALTER TABLE it's not at
> all clear how to do this or even wh
On 11/17/2010 08:32 AM, Aram Fingal wrote:
I have a table where I should have declared a foreign key with ON UPDATE
CASCADE and didn't. Now I want to fix that. From the documentation on
www.postgresql.org, about ALTER TABLE it's not at all clear how to do this or
even whether you can do this
I have a table where I should have declared a foreign key with ON UPDATE
CASCADE and didn't. Now I want to fix that. From the documentation on
www.postgresql.org, about ALTER TABLE it's not at all clear how to do this or
even whether you can do this.
-Aram
--
Sent via pgsql-general mailing
On 11/05/2010 05:19 PM, Tom Lane wrote:
> and even if it does, the
> likely behavior would be that the serializable transaction would fail
> outright rather than give you a surprising view of the table.
thanks for your answer,
I have to say that I would prefer an error in the serializable
transac
=?ISO-8859-1?Q?S=E9bastien_Lardi=E8re?= writes:
> I've got a problem with a query run on production system. We've got some
> data export in a serializable transaction, and, 2 days ago, someone ran
> a DDL ( alter table foo add column ba test default 'blabla'), and then,
> the data export is empty.
On 11/05/2010 04:28 PM, Sébastien Lardière wrote:
> Hi,
>
> I've got a problem with a query run on production system. We've got some
> data export in a serializable transaction, and, 2 days ago, someone ran
> a DDL ( alter table foo add column ba test default 'blabla'), and then,
> the data export
Hi,
I've got a problem with a query run on production system. We've got some
data export in a serializable transaction, and, 2 days ago, someone ran
a DDL ( alter table foo add column ba test default 'blabla'), and then,
the data export is empty. I try to reproduce the scenario below :
begin ;
dr
On 20 September 2010 20:58, Merlin Moncure wrote:
> On Mon, Sep 20, 2010 at 10:08 AM, Thom Brown wrote:
>> On 20 September 2010 14:53, Carlos Mennens wrote:
>>> I have a table in my database and would like to modify the one column
>>> that is already configured to be the PRIMARY KEY but I forgot
On Mon, Sep 20, 2010 at 10:08 AM, Thom Brown wrote:
> On 20 September 2010 14:53, Carlos Mennens wrote:
>> I have a table in my database and would like to modify the one column
>> that is already configured to be the PRIMARY KEY but I forgot to set
>> it for AUTO_INCREMENT. For some reason I can'
Thanks all! I understand the concept now.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 20 September 2010 19:54, Carlos Mennens wrote:
> On Mon, Sep 20, 2010 at 2:43 PM, A.M. wrote:
>> DEFAULT
>
> Sorry just to be clear you're saying that I need to enter the command as:
>
> INSERT INTO table_name DEFAULT VALUES (
> 'data',
> 'data',
> 'data',
> 'data',
> '2010-09-20'
> );
>
Well
On 09/20/2010 11:40 AM, Carlos Mennens wrote:
On Mon, Sep 20, 2010 at 10:08 AM, Thom Brown wrote:
CREATE SEQUENCE seq_blades_id;
SELECT setval('seq_blades_id', max(id)) FROM blades; -- set the
sequence's value to the maximum value of "id"
ALTER TABLE blades ALTER COLUMN id SET DEFAULT
nextval('
On 20 September 2010 19:40, Carlos Mennens wrote:
> On Mon, Sep 20, 2010 at 10:08 AM, Thom Brown wrote:
>> CREATE SEQUENCE seq_blades_id;
>> SELECT setval('seq_blades_id', max(id)) FROM blades; -- set the
>> sequence's value to the maximum value of "id"
>> ALTER TABLE blades ALTER COLUMN id SET D
On Mon, Sep 20, 2010 at 2:43 PM, A.M. wrote:
> DEFAULT
Sorry just to be clear you're saying that I need to enter the command as:
INSERT INTO table_name DEFAULT VALUES (
'data',
'data',
'data',
'data',
'2010-09-20'
);
Or does the 'DEFAULT' value go in ( )?
--
Sent via pgsql-general mailing lis
On Mon, Sep 20, 2010 at 10:08 AM, Thom Brown wrote:
> CREATE SEQUENCE seq_blades_id;
> SELECT setval('seq_blades_id', max(id)) FROM blades; -- set the
> sequence's value to the maximum value of "id"
> ALTER TABLE blades ALTER COLUMN id SET DEFAULT
> nextval('seq_blades_id'); -- make default value
On 20 September 2010 14:53, Carlos Mennens wrote:
> I have a table in my database and would like to modify the one column
> that is already configured to be the PRIMARY KEY but I forgot to set
> it for AUTO_INCREMENT. For some reason I can't find what the proper
> command would be in the documenta
I have a table in my database and would like to modify the one column
that is already configured to be the PRIMARY KEY but I forgot to set
it for AUTO_INCREMENT. For some reason I can't find what the proper
command would be in the documentation and my commands from MySQL don't
appear to work proper
On Fri, Sep 17, 2010 at 4:32 PM, Michael Glaesemann
wrote:
> This isn't valid syntax: I believe you issued UPDATE users
Woops. I did use the UPDATE and not ALTER command.
On Fri, Sep 17, 2010 at 4:39 PM, Richard Broersma
wrote:
> On Fri, Sep 17, 2010 at 1:32 PM, Michael Glaesemann
> wrote:
On Fri, Sep 17, 2010 at 1:32 PM, Michael Glaesemann
wrote:
> Postgres (nor any other SQL RDBMS) does not guarantee row order unless you
> specify it with an ORDER BY clause.
This is true, but some database will maintain a tables clustering.
MS-Access comes to mind. I don't know if MySQL does t
On Sep 17, 2010, at 16:12 , Carlos Mennens wrote:
> I noticed that my database was in order based on my primary key column
> called 'id' which when from 1 (first) to 6 (last). Today I had to edit
> table data which wasn't anything crazy:
>
> team=#ALTER users SET name = 'David' WHERE id = '1';
>
On Fri, Sep 17, 2010 at 4:12 PM, Carlos Mennens
wrote:
> Thanks for any assistance or clarification.
>
Rows in SQL are unordered. If you want an ordering, specify one on your SELECT.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
htt
I noticed that my database was in order based on my primary key column
called 'id' which when from 1 (first) to 6 (last). Today I had to edit
table data which wasn't anything crazy:
team=#ALTER users SET name = 'David' WHERE id = '1';
UPDATE 1
Now when I do a 'SELECT * FROM users' command in Post
Jeff,
One way to address the indefinite locking due to an ALTER TABLE
statement for PostgreSQL is to use ChronicDB. It allows you to apply
such a schema change live, without bringing down the database.
The space requirements for applying the live schema change would be to
have at least twice as m
On Tue, 2010-07-27 at 20:38 +, Leif Gunnar Erlandsen wrote:
> I want to move one table from one disk to another.
>
> In order to do this I wanted to create a new tablespace on the new disks and
> issue the command alter table tablename set tablespace tablespacename;
>
> The question is, will
I want to move one table from one disk to another.
In order to do this I wanted to create a new tablespace on the new disks and
issue the command alter table tablename set tablespace tablespacename;
The question is, will this in any way affect the database which is in heavily
use?
The table in q
Sim Zacks writes:
>> I haven't consumed enough caffeine today to recall the details, but
>> I think you could have ended up with default expressions like the above
>> if the database had been dumped and reloaded from 8.0 or earlier.
>> nextval(regclass) was introduced in 8.1 precisely to solve thi
> I haven't consumed enough caffeine today to recall the details, but
> I think you could have ended up with default expressions like the above
> if the database had been dumped and reloaded from 8.0 or earlier.
> nextval(regclass) was introduced in 8.1 precisely to solve this type
> of problem.
>
Sim Zacks writes:
>> id integer NOT NULL DEFAULT
>> nextval(('public.tblname_id_seq'::text)::regclass)
> Shouldn't this change automatically as well?
It would have changed automatically if the default expression were what
it's supposed to be, namely nextval('sequencename'::regclass). What
you'v
On 6/29/2010 4:24 PM, A. Kretschmer wrote:
> In response to Scott Marlowe :
>
>> On Tue, Jun 29, 2010 at 8:20 AM, A. Kretschmer
>> wrote:
>>
>>>
>>> Just for info: works well with 8.4:
>>>
>> Works in 8.3.9 on ubuntu 9.10...
>>
>>
> I think, this is the problem:
> You have cr
In response to Scott Marlowe :
> On Tue, Jun 29, 2010 at 8:20 AM, A. Kretschmer
> wrote:
> >
> >
> > Just for info: works well with 8.4:
>
> Works in 8.3.9 on ubuntu 9.10...
>
I think, this is the problem:
You have created the table first and later the sequence, like this:
test=# create table
On 6/29/2010 3:49 PM, Scott Marlowe wrote:
> On Tue, Jun 29, 2010 at 8:20 AM, A. Kretschmer
> wrote:
>
>> In response to Sim Zacks :
>>
>>> I am using 8.2.17
>>>
>>> I added a new schema and moved tables into it using
>>>
>>> ALTER TABLE tblname SET SCHEMA newschema;
>>>
>>>
>>> This mov
On Tue, Jun 29, 2010 at 8:20 AM, A. Kretschmer
wrote:
> In response to Sim Zacks :
>> I am using 8.2.17
>>
>> I added a new schema and moved tables into it using
>>
>> ALTER TABLE tblname SET SCHEMA newschema;
>>
>>
>> This moves the sequences referred to by the table to the new schema as
>> is sp
In response to Sim Zacks :
> I am using 8.2.17
>
> I added a new schema and moved tables into it using
>
> ALTER TABLE tblname SET SCHEMA newschema;
>
>
> This moves the sequences referred to by the table to the new schema as
> is specified by the manual.
>
> > Associated indexes, constraints,
I am using 8.2.17
I added a new schema and moved tables into it using
ALTER TABLE tblname SET SCHEMA newschema;
This moves the sequences referred to by the table to the new schema as
is specified by the manual.
> Associated indexes, constraints, and sequences owned by table columns
> are moved
On Wed, May 5, 2010 at 7:31 AM, Thom Brown wrote:
> On 5 May 2010 13:14, Chris Barnes wrote:
>>
>> It has been some years since I worked with Oracle, doesn't Oracle
>> recompile the view when the object it references changes in structure?
>> Send
>
> What does Oracle do when you've got a view lik
2010/5/5 Sim Zacks :
> One of the biggest problems I have maintaining a database with a lot of
> views is that when I want to change a datatype, I have to drop every
> view uses the column and every view that uses those views etc...
> This turns into a maintenance nightmare.
Then I would question
On 5 May 2010 13:14, Chris Barnes wrote:
>
> It has been some years since I worked with Oracle, doesn't Oracle recompile
> the view when the object it references changes in structure?
> Send
>
What does Oracle do when you've got a view like:
CREATE OR REPLACE VIEW test_view AS
SELECT test.test
It has been some years since I worked with Oracle, doesn't Oracle recompile the
view when the object it references changes in structure?
Send
From: thombr...@gmail.com
Date: Wed, 5 May 2010 10:12:34 +0100
Subject: Re: [GENERAL] alter table alter type CASCADE
To: s...@compulab.co.
2010/5/5 Sim Zacks
> One of the biggest problems I have maintaining a database with a lot of
> views is that when I want to change a datatype, I have to drop every
> view uses the column and every view that uses those views etc...
> This turns into a maintenance nightmare.
>
> Is there any intent
One of the biggest problems I have maintaining a database with a lot of
views is that when I want to change a datatype, I have to drop every
view uses the column and every view that uses those views etc...
This turns into a maintenance nightmare.
Is there any intention of adding a CASCADE to alter
Op 19-12-09 22:20, Jaime Casanova schreef:
are you planning to run this many times? what is wrong with making
this manually?
doesn't seem like something to make automatic...
but if you insist in plpgsql you can execute "select version() into
some_text_var" and act acordingly
No, this is don
On Sat, Dec 19, 2009 at 4:07 PM, Antonio Goméz Soto
wrote:
> Hi,
>
> is there a way in sql to dynamically test for version 7.3, so I can run the
>
are you planning to run this many times? what is wrong with making
this manually?
doesn't seem like something to make automatic...
but if you insist
Hi,
is there a way in sql to dynamically test for version 7.3, so I can run the
alter table add column
update table set column = .. where column IS NULL;
alter table alter column set not null
on 7.3, and on newer versions:
alter table add column ... not null default '';
Maybe I can cr
Op 17-12-09 23:46, Tom Lane schreef:
This is just one of many many things that could be improved by getting
off of 7.3. In general, complaining about performance (or features)
of a seven-year-old, long since EOL'd release is not a productive use of
anybody's time.
I'm sorry, didn't mean to
Thomas Kellerer writes:
> What's wrong with:
> alter table person add column address varchar(64) not null default '';
This:
regression=# alter table person add column address varchar(64) not null default
'';
ERROR: Adding columns with defaults is not implemented.
Add the column, then u
1 - 100 of 193 matches
Mail list logo
