Tino Wildenhain wrote:
> And which is quite easily done by:
>
> [ some SQL commands ]
Yeah, there are workarounds, but they have limitations -- they don't
work with FKs, they don't work if there's inheritance, they lose
indexes, and so on. They remind me how our CLUSTER command worked in
7.1. F
Alvaro Herrera wrote:
Michael Gould wrote:
...
doesn't need to look at the overflow page. I don't know if this is true or
not in PostGres. If it isn't then I'm not sure what difference it would
make other than allowing for "pretty" documentation.
Postgres does not overflow pages. Tuples ar
Michael Gould wrote:
> I come from the Sybase world and more SQL Anywhere. This is a feature that
> has been asked for on several occassions. I believe that it is on the
> feature list for V12. The only reason that it has been asked for is because
> of how rows are stored on a page. Only the 1s
- Original Message -
From: Adam Rich
To: Sam Mason ; vinny
Cc: pgsql-general@postgresql.org
Sent: Monday, August 24, 2009 2:58 PM
Subject: Re: R: [GENERAL] Field's position in Table
From: vinny
Subject: Re: R: [GENERAL] Field's positio
John R Pierce wrote:
> otoh, reordering the fields in a table would likely require a global
> exclusive access lock on the table for the duration of the
> operation, which for a large table could be substantial.
Obviously you haven't read the previous proposal on how to handle it.
It doesn't requ
Adam Rich wrote:
For me, saying all new fields must go at the end of the table is like
saying all new functions must go at the end of your C source file.
Not that it makes *any* difference to the end user, or other
applications using your libraries, but as developers we tend to
be more organi
Adam Rich wrote:
> For me, saying all new fields must go at the end of the table is like
> saying all new functions must go at the end of your C source file.
> Not that it makes *any* difference to the end user, or other
> applications using your libraries, but as developers we tend to
> be more
From: vinny
Subject: Re: R: [GENERAL] Field's position in Table
To: "Sam Mason"
Cc: pgsql-general@postgresql.org
Date: Monday, August 24, 2009, 2:38 PM
On Thu, 2009-08-20 at 12:16 +0100, Sam Mason wrote:
> On Thu, Aug 20, 2009 at 11:24:49AM +0200, vinny wrote:
> > I c
On Thu, 2009-08-20 at 12:16 +0100, Sam Mason wrote:
> On Thu, Aug 20, 2009 at 11:24:49AM +0200, vinny wrote:
> > I can't really think of any real reason to put the field at a
> > particular position, applications don't reallty care about the order
> > of fields.
>
> Because it's very convenient fo
On Thu, Aug 20, 2009 at 7:45 PM, Yaroslav Tykhiy wrote:
> On 20/08/2009, at 7:24 PM, vinny wrote:
>
>> I can't really think of any real reason to put the field at a particular
>> position, applications
>> don't reallty care about the order of fields.
>
> ... unless an application is brain-damaged b
On 20/08/2009, at 7:24 PM, vinny wrote:
I can't really think of any real reason to put the field at a
particular
position, applications
don't reallty care about the order of fields.
... unless an application is brain-damaged by its using a wildcard
select, which is a well-known no-no even
On Thu, Aug 20, 2009 at 11:24:49AM +0200, vinny wrote:
> I can't really think of any real reason to put the field at a
> particular position, applications don't reallty care about the order
> of fields.
Because it's very convenient for ad-hoc queries! PG currently assumes
that the column order is
On Thu, 20 Aug 2009 09:21:25 + (GMT), Scara Maccai
wrote:
>> When adding a new field in the existing table, i
>> want to add the filed in a particular position.
>
> I'm afraid the only way would be re-writing the whole table (pseudo
sql):
>
> BEGIN;
> create table newtable as select field1,
13 matches
Mail list logo
