Zeugswetter Andreas ADI SD escribió:
>
> > > And I also see a lot of unhappiness from users of system tables
> > > when column numbers all over the system tables would not be
> > > logical column positions any more.
> >
> > Right now the fact that attnum presents the logical order but
> > not the logical position is a problem for the JDBC driver.
> > In the presence of dropped columns there is no easy way to
> > get from a pg_attribute entry to logical position. I would
> > hope that a new logical position column would reflect the
> > actual position and solve this problem.
>
> I agree, I haven't thought of drop column :-( Drop column should have
> relabeled attnum.
> Since it was not done then, my comments are probably moot.

We can correct this problem now.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

On Thu, 22 Feb 2007, Alvaro Herrera wrote:

> Zeugswetter Andreas ADI SD escribió:
>>
>> I agree, I haven't thought of drop column :-( Drop column should have
>> relabeled attnum. Since it was not done then, my comments are probably
>> moot.
>
> We can correct this problem now.
>

How? If attnum is serving as both physical position and logical order,
how can you make it be logical position without breaking physical
position?

Kris Jurka

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Kris Jurka escribió:
>
>
> On Thu, 22 Feb 2007, Alvaro Herrera wrote:
>
> >Zeugswetter Andreas ADI SD escribió:
> >>
> >>I agree, I haven't thought of drop column :-( Drop column should have
> >>relabeled attnum. Since it was not done then, my comments are probably
> >>moot.
> >
> >We can correct this problem now.
>
> How? If attnum is serving as both physical position and logical order,
> how can you make it be logical position without breaking physical
> position?

By patching the code, of course, so that it doesn't serves as both
things, which is what is being discussed.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

> > I agree, I haven't thought of drop column :-( Drop column should
have
> > relabeled attnum.
> > Since it was not done then, my comments are probably moot.
>
> We can correct this problem now.

Do you mean fix it with the 3rd column in pg_attribute and use that,
or fix attnum ? :-)

Imho it is a pain to need 2 numbers and a mapping in drivers.

Andreas

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

> >> I agree, I haven't thought of drop column :-( Drop column should
have
> >> relabeled attnum. Since it was not done then, my comments are
> >> probably moot.
> >
> > We can correct this problem now.
>
> How? If attnum is serving as both physical position and
> logical order, how can you make it be logical position
> without breaking physical position?

If you ask me, attnum would be the logical position and would be used
in all other system tables. attphypos would only be used in
pg_attribute.
It would be quite some work to rearrange attnum in all system tables for
"drop column" and "add column before", but it would be nice for jdbc.

But it seems others want this: attnum beeing an arbitrary number,
that is used in all system tables and 2 extra columns in pg_attribute,
one for logical position and one for physical position.
If you want a corresponding colname to a pg_index attnum you need a map.

Andreas

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On 2/20/07, Phil Currier <pcurrier@gmail.com> wrote:
> Inspired by this thread [1], and in particular by the idea of storing
> three numbers (permanent ID, on-disk storage position, display
> position) for each column, I spent a little time messing around with a
> prototype implementation of column storage positions to see what kind
> of difference it would make.

Phil, did you make any progress with your patch? Your results seemed
very encouraging and your implementation interesting.
IIRC, the problem was that you weren't interested in working on the
"visual/mysqlish" column ordering. As the plan was to decouple column
ordering in three different orderings, I don't think it's really a
problem if your implementation doesn't support one of them (at least
if it doesn't prevent us from having the visual one someday).

Is there any chance you keep us posted with your progress and post a
preliminary patch exposing your design choices? This could allow other
people to see if there are interesting results with their particular
database and workload.

It's too late for 8.3 but it could be a nice thing to have in 8.4.

Thanks in advance.

Regards.

--
Guillaume

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

On 4/1/07, Guillaume Smet <guillaume.smet@gmail.com> wrote:
> Phil, did you make any progress with your patch? Your results seemed
> very encouraging and your implementation interesting.
> IIRC, the problem was that you weren't interested in working on the
> "visual/mysqlish" column ordering. As the plan was to decouple column
> ordering in three different orderings, I don't think it's really a
> problem if your implementation doesn't support one of them (at least
> if it doesn't prevent us from having the visual one someday).

I haven't done much with it since February, largely because my
available free time evaporated. But I do intend to get back to it
when I have a chance. But you're right, the storage position stuff
I've worked on is completely independent from display positions, and
certainly wouldn't prevent that being added separately.

> Is there any chance you keep us posted with your progress and post a
> preliminary patch exposing your design choices? This could allow other
> people to see if there are interesting results with their particular
> database and workload.

Yeah, I'll try to clean things up and post a patch eventually. And if
anyone feels like working on the display position piece, let me know;
perhaps we could pool our efforts for 8.4.

phil

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Phil Currier wrote:
> I haven't done much with it since February, largely because my
> available free time evaporated. But I do intend to get back to it
> when I have a chance. But you're right, the storage position stuff
> I've worked on is completely independent from display positions, and
> certainly wouldn't prevent that being added separately.

I agree with this comment from Tom last time it was discussed:

> In any case I think it's foolish not to tackle both issues at once.
> We know we'd like to have both features and we know that all the same
> bits of code need to be looked at to implement either.

Just tackling the side of the problem that interests you is probably not
the ideal way to go.


cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

On Mon, Apr 2, 2007 at 2:44 AM, Phil Currier <pcurrier@gmail.com> wrote:
> On 4/1/07, Guillaume Smet <guillaume.smet@gmail.com> wrote:
>
> > Phil, did you make any progress with your patch? Your results seemed
> > very encouraging and your implementation interesting.
> > IIRC, the problem was that you weren't interested in working on the
> > "visual/mysqlish" column ordering. As the plan was to decouple column
> > ordering in three different orderings, I don't think it's really a
> > problem if your implementation doesn't support one of them (at least
> > if it doesn't prevent us from having the visual one someday).
> >
>
> I haven't done much with it since February, largely because my
> available free time evaporated. But I do intend to get back to it
> when I have a chance. But you're right, the storage position stuff
> I've worked on is completely independent from display positions, and
> certainly wouldn't prevent that being added separately.
>
>
>
> > Is there any chance you keep us posted with your progress and post a
> > preliminary patch exposing your design choices? This could allow other
> > people to see if there are interesting results with their particular
> > database and workload.
> >
>
> Yeah, I'll try to clean things up and post a patch eventually. And if
> anyone feels like working on the display position piece, let me know;
> perhaps we could pool our efforts for 8.4.

Hi Phil,

Did you make any progress on this cleanup? It seems like a good timing
to revive this project if we want it for 8.4.

Thanks for your feedback.

--
Guillaume

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers