Here is the patch to fix that, as discussed.
diff --git i/src/bin/pg_dump/pg_dump.c w/src/bin/pg_dump/pg_dump.c
index c2f6180..afc7fd7 100644
--- i/src/bin/pg_dump/pg_dump.c
+++ w/src/bin/pg_dump/pg_dump.c
@@ -12004,7 +12004,11 @@ dumpTableSchema(Archive *fout, TableInfo *tbinfo)
UNLOGGED
Peter Eisentraut pete...@gmx.net writes:
Here is the patch to fix that, as discussed.
Looks sane --- I assume you tested it against the originally
complained-of scenario?
http://archives.postgresql.org/message-id/201103111328.p2bdsfd10...@momjian.us
If so, please apply soon --- we need to wrap
On Wed, Apr 27, 2011 at 09:30:41PM +0300, Peter Eisentraut wrote:
Here is the patch to fix that, as discussed.
Looks correct. Thanks.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Mar 30, 2011 at 09:32:08PM -0400, Noah Misch wrote:
... ALTER TYPE mistakenly
only touches the first table-of-type:
create type t as (x int, y int);
create table is_a of t;
create table is_a2 of t;
alter type t drop attribute y cascade, add attribute z int cascade;
\d is_a
On Wed, Mar 30, 2011 at 9:32 PM, Noah Misch n...@leadboat.com wrote:
Incidentally, this led me to notice that you can hang a typed
table off a table row type. ALTER TABLE never propagates to such typed
tables,
allowing them to get out of sync:
create table t (x int, y int);
create table
On Wed, Mar 30, 2011 at 12:50 PM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2011-02-10 at 06:31 +0200, Peter Eisentraut wrote:
ERROR: cannot drop column from typed table
which probably is because test_type2 has a dropped column.
It should call
ALTER TYPE test_type2 DROP ATTRIBUTE
On Fri, Apr 08, 2011 at 03:43:39PM -0400, Robert Haas wrote:
On Wed, Mar 30, 2011 at 9:32 PM, Noah Misch n...@leadboat.com wrote:
Incidentally, this led me to notice that you can hang a typed
table off a table row type. ?ALTER TABLE never propagates to such typed
tables,
allowing them to
On ons, 2011-04-06 at 11:49 -0400, Noah Misch wrote:
Peter, were you planning to complete this? I can take a swing at it, if it
would be helpful.
Help is always welcome.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Apr 05, 2011 at 09:44:44AM -0400, Robert Haas wrote:
On Wed, Mar 30, 2011 at 9:32 PM, Noah Misch n...@leadboat.com wrote:
On Wed, Mar 30, 2011 at 07:50:12PM +0300, Peter Eisentraut wrote:
Here is a patch that addresses this problem.
This only works when exactly one typed table
On Wed, Mar 30, 2011 at 9:32 PM, Noah Misch n...@leadboat.com wrote:
On Wed, Mar 30, 2011 at 07:50:12PM +0300, Peter Eisentraut wrote:
On tor, 2011-02-10 at 06:31 +0200, Peter Eisentraut wrote:
ERROR: cannot drop column from typed table
which probably is because test_type2 has a
On tor, 2011-02-10 at 06:31 +0200, Peter Eisentraut wrote:
ERROR: cannot drop column from typed table
which probably is because test_type2 has a dropped column.
It should call
ALTER TYPE test_type2 DROP ATTRIBUTE xyz CASCADE;
instead. That will propagate to the table.
Here is a
On Wed, Mar 30, 2011 at 07:50:12PM +0300, Peter Eisentraut wrote:
On tor, 2011-02-10 at 06:31 +0200, Peter Eisentraut wrote:
ERROR: cannot drop column from typed table
which probably is because test_type2 has a dropped column.
It should call
ALTER TYPE test_type2 DROP
On Fri, Mar 11, 2011 at 8:28 AM, Bruce Momjian br...@momjian.us wrote:
Is this still an open bug?
Is anyone working on fixing this?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Is this still an open bug?
---
Tom Lane wrote:
I find that pg_upgrade fails in HEAD when asked to do a 9.1-to-9.1
upgrade of the regression database. It gets to this bit of the
restore script:
CREATE TABLE test_tbl2
I find that pg_upgrade fails in HEAD when asked to do a 9.1-to-9.1
upgrade of the regression database. It gets to this bit of the
restore script:
CREATE TABLE test_tbl2 OF public.test_type2;
-- For binary upgrade, recreate dropped column.
UPDATE pg_catalog.pg_attribute
SET attlen = -1, attalign
Tom Lane wrote:
I find that pg_upgrade fails in HEAD when asked to do a 9.1-to-9.1
upgrade of the regression database. It gets to this bit of the
restore script:
CREATE TABLE test_tbl2 OF public.test_type2;
-- For binary upgrade, recreate dropped column.
UPDATE pg_catalog.pg_attribute
On ons, 2011-02-09 at 18:43 -0500, Tom Lane wrote:
I find that pg_upgrade fails in HEAD when asked to do a 9.1-to-9.1
upgrade of the regression database. It gets to this bit of the
restore script:
CREATE TABLE test_tbl2 OF public.test_type2;
-- For binary upgrade, recreate dropped
On ons, 2011-02-09 at 23:16 -0500, Bruce Momjian wrote:
I am not aware of this code changing in 9.1. Was this test in 9.0?
Does this problem happen for 9.0?
No, because you can't drop anything from a typed table in 9.0.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On mån, 2010-01-11 at 19:27 -0500, Andrew Chernow wrote:
Peter Eisentraut wrote:
On mån, 2010-01-11 at 15:02 -0500, Andrew Chernow wrote:
ISTM that the ultimate would be a 'create table (_) without storage'
(or some'm) and make 'create type' an alternate syntax for SQL
conformance.
2010/1/12 Peter Eisentraut pete...@gmx.net:
On mån, 2010-01-11 at 19:27 -0500, Andrew Chernow wrote:
Peter Eisentraut wrote:
On mån, 2010-01-11 at 15:02 -0500, Andrew Chernow wrote:
ISTM that the ultimate would be a 'create table (_) without storage'
(or some'm) and make 'create type'
Peter Eisentraut wrote:
On mån, 2010-01-11 at 19:27 -0500, Andrew Chernow wrote:
Peter Eisentraut wrote:
On mån, 2010-01-11 at 15:02 -0500, Andrew Chernow wrote:
ISTM that the ultimate would be a 'create table (_) without storage'
(or some'm) and make 'create type' an alternate syntax for
On tis, 2010-01-12 at 08:05 -0500, Andrew Chernow wrote:
In practice, tables can be used for passing data around or storing it on
disk.
So, I guess my question remains unanswered as to what the composite type
offers
that a table doesn't; other than a name that better suits the task.
The
Peter Eisentraut wrote:
On tis, 2010-01-12 at 08:05 -0500, Andrew Chernow wrote:
In practice, tables can be used for passing data around or storing it on disk.
So, I guess my question remains unanswered as to what the composite type offers
that a table doesn't; other than a name that
What is the point of this discussion? We're not going to remove the
facility for composite types, regardless of whether or not some people
regard them as unnecessary. And a name that better suits the task is
not to be sneered at anyway.
I never asked for anything to be removed nor do I
On Tue, Jan 12, 2010 at 9:00 AM, Andrew Dunstan and...@dunslane.net wrote:
What is the point of this discussion? We're not going to remove the facility
for composite types, regardless of whether or not some people regard them as
unnecessary. And a name that better suits the task is not to be
On tis, 2010-01-12 at 09:54 -0500, Merlin Moncure wrote:
*) should 'create type as' get an 'alter'? ( I think most would think so)
Working on that right now ...
*) if so, how do you distinguish between the composite and non
composite version? How would this command look?
I'm only dealing
On 01/12/2010 06:43 AM, Andrew Chernow wrote:
What is the point of this discussion? We're not going to remove the
facility for composite types, regardless of whether or not some people
regard them as unnecessary. And a name that better suits the task is
not to be sneered at anyway.
I
On Mon, Nov 9, 2009 at 5:15 AM, Peter Eisentraut pete...@gmx.net wrote:
On Sun, 2009-11-08 at 21:17 +, Simon Riggs wrote:
Not sure I see why this is good. Why is issuing CREATE TYPE so much
easier than using CREATE TABLE? Is it worth the extra syntax and code to
support it? Can we do
Peter,
Typed tables is the official SQL standard name for the feature, and
it's also used in DB2 documentation. So I kind of would prefer to keep
it.
Sorry, I missed the SQL standard part in the thread. Ignore the noise.
Oh, and BTW, +1 on accepting this, pending patch quality and all
Peter Eisentraut wrote:
On tor, 2009-11-05 at 19:24 +0200, Peter Eisentraut wrote:
I'm planning to work on typed tables support. The idea is that you
create a table out of a composite type (as opposed to the other way
around, which is currently done automatically).
CREATE TYPE persons_type AS
On mån, 2010-01-11 at 15:02 -0500, Andrew Chernow wrote:
ISTM that the ultimate would be a 'create table (_) without storage'
(or some'm) and make 'create type' an alternate syntax for SQL
conformance.
I don't really understand the purpose of that.
For various reasons, we've
Peter Eisentraut wrote:
On mån, 2010-01-11 at 15:02 -0500, Andrew Chernow wrote:
ISTM that the ultimate would be a 'create table (_) without storage'
(or some'm) and make 'create type' an alternate syntax for SQL
conformance.
I don't really understand the purpose of that.
What is the
On tor, 2009-11-05 at 19:24 +0200, Peter Eisentraut wrote:
I'm planning to work on typed tables support. The idea is that you
create a table out of a composite type (as opposed to the other way
around, which is currently done automatically).
CREATE TYPE persons_type AS (name text, bdate
On 1/10/10 2:34 PM, Peter Eisentraut wrote:
On tor, 2009-11-05 at 19:24 +0200, Peter Eisentraut wrote:
I'm planning to work on typed tables support. The idea is that you
create a table out of a composite type (as opposed to the other way
around, which is currently done automatically).
Nice.
On sön, 2010-01-10 at 15:27 -0800, Josh Berkus wrote:
On 1/10/10 2:34 PM, Peter Eisentraut wrote:
On tor, 2009-11-05 at 19:24 +0200, Peter Eisentraut wrote:
I'm planning to work on typed tables support. The idea is that you
create a table out of a composite type (as opposed to the other
On Sun, 2009-11-08 at 21:17 +, Simon Riggs wrote:
Not sure I see why this is good. Why is issuing CREATE TYPE so much
easier than using CREATE TABLE? Is it worth the extra syntax and code to
support it? Can we do anything additional as a result of this?
These are tools to improve database
On Mon, 2009-11-09 at 12:15 +0200, Peter Eisentraut wrote:
Is this required by the standard or are we going past the standard?
This is part of the SQL standard.
+1
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Thu, 2009-11-05 at 19:24 +0200, Peter Eisentraut wrote:
This is useful in conjunction with PL/Proxy and similar RPC-type
setups. On the frontend/proxy instances you only create the type, and
the backend instances you create the storage for the type, and the
database system would give you a
This is useful in conjunction with PL/Proxy and similar RPC-type
setups. On the frontend/proxy instances you only create the type, and
the backend instances you create the storage for the type, and the
database system would give you a little support keeping them in sync.
Think interface
On Nov 5, 2009, at 10:24 AM, Peter Eisentraut wrote:
One thing I'm not sure of is whether to keep the implicit row type in
that case. That is, would the above command sequence still create a
persons type? We could keep that so as to preserve the property a
table always has a row type of the
On tor, 2009-11-05 at 12:38 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
One thing I'm not sure of is whether to keep the implicit row type in
that case. That is, would the above command sequence still create a
persons type?
Are you intending that the table and the
On tor, 2009-11-05 at 11:41 -0700, James Pye wrote:
Any plans to allow the specification of multiple types to define the
table?
CREATE TABLE employee OF employee_data_type, persons_data_type;
Not really, but it does open up interesting possibilities, if we just
allow composite types to
On Thu, Nov 5, 2009 at 12:24 PM, Peter Eisentraut pete...@gmx.net wrote:
I'm planning to work on typed tables support. The idea is that you
create a table out of a composite type (as opposed to the other way
around, which is currently done automatically).
CREATE TYPE persons_type AS (name
Merlin Moncure wrote:
On Thu, Nov 5, 2009 at 12:24 PM, Peter Eisentraut pete...@gmx.net wrote:
I'm planning to work on typed tables support. The idea is that you
create a table out of a composite type (as opposed to the other way
around, which is currently done automatically).
CREATE TYPE
Peter Eisentraut pete...@gmx.net wrote:
On tor, 2009-11-05 at 11:41 -0700, James Pye wrote:
CREATE TABLE employee OF employee_data_type, persons_data_type;
Not really, but it does open up interesting possibilities, if we just
allow composite types to participate in inheritance
45 matches
Mail list logo
