yes, that's on the todo list.you can search back in the archives for
discussions on how to do this without making the code difficult to debug.
this is a bug but it's a longstanding known bug inan area where we have
lots of known limitations and nobody is too excited about spending lots of
effort
I'm think you should add some abstract-layer for handling column ordering
not as they stored at disk. It is possible?
On Fri, Feb 26, 2010 at 10:32 PM, Alvaro Herrera wrote:
> Tom Lane escribió:
> > Oleg Serov writes:
> > > So there are no simple way to do it right, and it will be not fixed?
>
On Fri, Feb 26, 2010 at 9:29 PM, Tom Lane wrote:
> Oleg Serov writes:
> > So there are no simple way to do it right, and it will be not fixed? Will
> > this bug appear in todo list?
>
> It's not a bug, it's just what happens when you make the parent and
>
It is a bug. If i'm doing dump restore i
Tom Lane escribió:
> Oleg Serov writes:
> > So there are no simple way to do it right, and it will be not fixed? Will
> > this bug appear in todo list?
>
> It's not a bug, it's just what happens when you make the parent and
> child column orders inconsistent. Would you prefer that we restricted
Oleg Serov writes:
> So there are no simple way to do it right, and it will be not fixed? Will
> this bug appear in todo list?
It's not a bug, it's just what happens when you make the parent and
child column orders inconsistent. Would you prefer that we restricted
ALTER TABLE to refuse to perfor
So there are no simple way to do it right, and it will be not fixed? Will
this bug appear in todo list?
On Fri, Feb 26, 2010 at 6:13 PM, Greg Stark wrote:
> 2010/2/26 Oleg Serov :
> > Up! Anybody will answer about the patch?
>
> The patch causes the inheritance history to be lost. If you
> subse
2010/2/26 Oleg Serov :
> Up! Anybody will answer about the patch?
The patch causes the inheritance history to be lost. If you
subsequently drop the column form the parent it'll be kept on the
child because it was explicitly declared when you created the child.
In the original structure if you drop
Up! Anybody will answer about the patch?
On Mon, Jul 6, 2009 at 11:20 AM, Oleg Serov wrote:
> How about adding this patch to postgresql it will slove the problem?
>
> On Sun, Jul 5, 2009 at 8:10 PM, Greg Stark wrote:
> > On Sun, Jul 5, 2009 at 4:28 PM, Tom Lane wrote:
> >> when i done dump->rest
How about adding this patch to postgresql it will slove the problem?
On Sun, Jul 5, 2009 at 8:10 PM, Greg Stark wrote:
> On Sun, Jul 5, 2009 at 4:28 PM, Tom Lane wrote:
>> when i done dump->restore i
>>> have surprise,
>>> Column ordering was changed.
>>
>> This is not a bug, it's the intended beh
Greg Stark writes:
> On Sun, Jul 5, 2009 at 4:28 PM, Tom Lane wrote:
>> This is not a bug, it's the intended behavior.
> I thought that was a bug, just one that was too hard to fix for the
> problems it caused. It might be more fixable if we get around to the
> work that was discussed earlier whe
On Sun, Jul 5, 2009 at 5:10 PM, Greg Stark wrote:
> On Sun, Jul 5, 2009 at 4:28 PM, Tom Lane wrote:
>> when i done dump->restore i
>>> have surprise,
>>> Column ordering was changed.
>>
>> This is not a bug, it's the intended behavior.
>
> I thought that was a bug
Rereading the thread I'll also me
On Sun, Jul 5, 2009 at 4:28 PM, Tom Lane wrote:
> when i done dump->restore i
>> have surprise,
>> Column ordering was changed.
>
> This is not a bug, it's the intended behavior.
I thought that was a bug, just one that was too hard to fix for the
problems it caused. It might be more fixable if we
Oleg Serov writes:
> If i have tables with inherits, and the
> n i adding a column in to the base table, the new column will be at
> the on of column list in child table, but when i done dump->restore i
> have surprise,
> Column ordering was changed.
This is not a bug, it's the intended behavior.
Here is the solution of this problem:
Patch
src/bin/pg_dump/pg_dump.c
appendPQExpBuffer(q, "CREATE TABLE %s (",
fmtId(tbinfo->dobj.name));
actual_atts = 0;
for (j = 0; j < tbinfo->numatts; j++)
{
/* Is this one of the table's own attrs, and not dropped ? */
- if (!tbinfo->inhAttrs[j] &&
- (!tbinfo
No, we can't do like this, because we have something like this:
CREATE TABLE test_base (
id INT
);
CREATE TABLE test_child_with_data (
t TEXT
) INHERITS (test_base);
ALTER TABLE test_base ADD COLUMN date DATE;
INSERT INTO test_child_with_data VALUES (1, 'text', NOW());
CREATE FU
If i have tables with inherits, and the
n i adding a column in to the base table, the new column will be at
the on of column list in child table, but when i done dump->restore i
have surprise,
Column ordering was changed.
Some example:
CREATE TABLE test_base (
id INT
);
CREATE TABLE test_c
16 matches
Mail list logo
