On Nov 25, 2008, at 9:41 PM, Robert Haas wrote:
Changing physical positioning is purely an internal matter. A
first-cut
implementation should probably just make it identical to logical
positioning, until the latter is changed by the user (after which,
physical positioning continues to reflect
"Robert Haas" <[EMAIL PROTECTED]> writes:
> Imagine for example:
> CREATE TABLE foo (c1 integer, c2 text, c3 boolean, c4 date, c5
> timestamp, c6 numeric, c7 varchar);
> CREATE OR REPLACE VIEW tricky AS SELECT * FROM foo AS bar (a, b, c);
> ALTER TABLE foo ALTER COLUMN c2 POSITION LAST;
> After s
On Tue, Nov 25, 2008 at 9:18 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
>> After some thought, it seems pretty clear, at least to me, that the
>> third (hypothetical) command should not change the result of "SELECT *
>> FROM tricky" (the contrary conclusion gives rise to a lot of problems,
>> es
Robert Haas escribió:
> After some thought, it seems pretty clear, at least to me, that the
> third (hypothetical) command should not change the result of "SELECT *
> FROM tricky" (the contrary conclusion gives rise to a lot of problems,
> especially if there are other views depending on it). But
> The ultimate conclusion was that a three-way split (identity, logical
> position, physical position) could work because most of the code only
> cares about column identity; the places where logical or physical
> positions are important are pretty narrowly circumscribed, or could
> be made so.
I
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Tue, Nov 25, 2008 at 03:10:30PM -0600, Decibel! wrote:
>> IIRC the community did come to a consensus on allowing for a
>> different logical ordering from physical ordering, it was an issue of
>> actually doing the work. If this is an itch
On Tue, Nov 25, 2008 at 03:10:30PM -0600, Decibel! wrote:
> IIRC the community did come to a consensus on allowing for a
> different logical ordering from physical ordering, it was an issue of
> actually doing the work. If this is an itch you want to scratch, you
> might look into fixing that
On Nov 14, 2008, at 12:12 PM, Tom Lane wrote:
"hernan gonzalez" <[EMAIL PROTECTED]> writes:
I've added an option to pg_dump to reorder
columns in the ouput "CREATE TABLE" dump.
This doesn't seem like a particularly good idea to me. In the first
place, pg_dump is a tool for reproducing your da
On Friday 14 November 2008 13:37:05 hernan gonzalez wrote:
> On Fri, Nov 14, 2008 at 4:12 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> > "hernan gonzalez" <[EMAIL PROTECTED]> writes:
> >> I've added an option to pg_dump to reorder
> >> columns in the ouput "CREATE TABLE" dump.
> >
> > This doesn't see
On Fri, Nov 14, 2008 at 4:12 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "hernan gonzalez" <[EMAIL PROTECTED]> writes:
>> I've added an option to pg_dump to reorder
>> columns in the ouput "CREATE TABLE" dump.
>
> This doesn't seem like a particularly good idea to me. In the first
> place, pg_dump i
"hernan gonzalez" <[EMAIL PROTECTED]> writes:
> I've added an option to pg_dump to reorder
> columns in the ouput "CREATE TABLE" dump.
This doesn't seem like a particularly good idea to me. In the first
place, pg_dump is a tool for reproducing your database, not altering it,
so it seems like basi
Hi.
As I wanted to change the order of columns of some tables (I know, I
know, my code does not depend
on that; but I prefer that \dt gives me a more organized ouput...)
I've added an option to pg_dump to reorder
columns in the ouput "CREATE TABLE" dump.
The specified order is given in a external f
12 matches
Mail list logo
