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
Peter Eisentraut 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 beta1 this even
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
On Fri, Apr 08, 2011 at 03:43:39PM -0400, Robert Haas wrote:
> On Wed, Mar 30, 2011 at 9:32 PM, Noah Misch 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
On Wed, Mar 30, 2011 at 12:50 PM, 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 ATTRIBU
On Wed, Mar 30, 2011 at 9:32 PM, Noah Misch 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 is_a of t;
>
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 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:
http://www.
On Tue, Apr 05, 2011 at 09:44:44AM -0400, Robert Haas wrote:
> On Wed, Mar 30, 2011 at 9:32 PM, Noah Misch 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 uses each c
On Wed, Mar 30, 2011 at 9:32 PM, Noah Misch 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 dropped c
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_t
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.
On Fri, Mar 11, 2011 at 8:28 AM, Bruce Momjian 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)
To make changes
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_t
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 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
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_attr
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
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.
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 Tue, Jan 12, 2010 at 9:00 AM, Andrew Dunstan 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
> anyw
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 s
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 better sui
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 bette
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.
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
2010/1/12 Peter Eisentraut :
> 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
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
> >> co
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 p
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 inter
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
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
On Mon, Nov 9, 2009 at 5:15 AM, Peter Eisentraut 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 anything addit
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
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).
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 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 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 databas
> > 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 i
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 yo
Peter Eisentraut 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 relationships.
>
Merlin Moncure wrote:
> On Thu, Nov 5, 2009 at 12:24 PM, 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 person
On Thu, Nov 5, 2009 at 12:24 PM, 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 d
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 type
On tor, 2009-11-05 at 12:38 -0500, Tom Lane wrote:
> Peter Eisentraut 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 origina
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
46 matches
Mail list logo
