Added to TODO:
o Allow column display reordering by recording a display,
storage, and permanent id for every column?
http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php
---
Jim C.
On Thu, Dec 21, 2006 at 11:43:27AM -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
You could make a case that we need *three* numbers: a permanent column
ID, a display position, and a storage position.
Could this not be handled by some catalog fixup after
You could make a case that we need *three* numbers: a permanent
column
ID, a display position, and a storage position.
Could this not be handled by some catalog fixup after an add/drop?
If we
get the having 3 numbers you will almost have me convinced that this
might be too
I'm not sure how much you can do with typing. Things like heap_getattr
are macros, and thus untyped. Most places use attr as an index to an
array, which also can't be type checked.
If you switched everything over to inline functions you might
get it to
work, but that's about it.
IMHO
Zeugswetter Andreas ADI SD wrote:
I'm not sure how much you can do with typing. Things like heap_getattr
are macros, and thus untyped. Most places use attr as an index to an
array, which also can't be type checked.
If you switched everything over to inline functions you might
get it to
work,
On Thu, Dec 21, 2006 at 10:27:12AM -0500, Andrew Dunstan wrote:
Um, surely you meant offset the physical numbers. Imho the logical
numbers
need to stay 1-n, because those numbers are used way more often and are
more user visible than the physical.
I don't think we should expose the
Martijn van Oosterhout kleptog@svana.org writes:
The thing is, physical index numbers has meaning, the logical index
number does not. In a view definition we're going to store the physical
index, not the logical one, for example.
Really? To me that's one of a large number of questions that
I don't think we should expose the offset to user view at all - this
is
just for internal use, no?
The thing is, physical index numbers has meaning, the logical index
number does not. In a view definition we're going to store the
physical
index, not the logical one, for example. We
On Thu, Dec 21, 2006 at 10:50:59AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
The thing is, physical index numbers has meaning, the logical index
number does not. In a view definition we're going to store the physical
index, not the logical one, for example.
On Thu, Dec 21, 2006 at 05:06:53PM +0100, Zeugswetter Andreas ADI SD wrote:
The thing is, physical index numbers has meaning, the logical index
number does not. In a view definition we're going to store the
physical index, not the logical one, for example. We don't want
rearranging columns
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Dec 21, 2006 at 10:50:59AM -0500, Tom Lane wrote:
Really? To me that's one of a large number of questions that are
unresolved about how we'd do this. You can make a case for either
choice in quite a number of places.
Can we? For
The thing is, physical index numbers has meaning, the logical
index
number does not. In a view definition we're going to store the
physical index, not the logical one, for example. We don't want
rearranging columns to invalidate view definitions or plans.
I think we lack a
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
On Thu, Dec 21, 2006 at 10:50:59AM -0500, Tom Lane wrote:
Really? To me that's one of a large number of questions that are
unresolved about how we'd do this. You can make a case for either
choice in quite a number of
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
You could make a case that we need *three* numbers: a permanent column
ID, a display position, and a storage position.
Could this not be handled by some catalog fixup after an add/drop? If we
get the having 3 numbers you will almost
On Thu, Dec 21, 2006 at 11:15:38AM -0500, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Can we? For anything of any permenence (view definitions, rules,
compiled functions, plans, etc) you're going to want the physical
number, for the same reason we store the oids of
Martijn van Oosterhout kleptog@svana.org writes:
I was envisiging the physical number to be fixed and immutable (ie
storage position = permanent position).
There are two different problems being discussed here, and one of them
is insoluble if we take that position: people would like the system
Tom Lane wrote:
Actually, the more I think about it the more I think that 3 numbers
might be the answer. 99% of the code would use only the permanent ID.
Display position would be used in *exactly* one place, namely while
expanding SELECT foo.* --- I can't think of any other part of the
backend
Tom Lane [EMAIL PROTECTED] writes:
Actually, the more I think about it the more I think that 3 numbers
might be the answer. 99% of the code would use only the permanent ID.
Don't we already have such a permanent number -- just one we don't use
anywhere in the data model? Namely the oid of the
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Actually, the more I think about it the more I think that 3 numbers
might be the answer. 99% of the code would use only the permanent ID.
Don't we already have such a permanent number -- just one we don't use
Tom Lane wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Force references to go through macros which implement the lookup for the
appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
It doesn't really address the question of how
On Tue, Dec 19, 2006 at 11:29:24PM -0500, Tom Lane wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Force references to go through macros which implement the lookup for the
appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
It
Am Mittwoch, 20. Dezember 2006 04:44 schrieb Tom Lane:
If you can show me a reasonably bulletproof or machine-checkable way to
keep the two kinds of column numbers distinct, I'd be all for it.
The only way I can see is to make the domains of the numbers distinct.
--
Peter Eisentraut
On Wed, Dec 20, 2006 at 07:20:14AM -0600, Kenneth Marshall wrote:
On Wed, Dec 20, 2006 at 01:26:59PM +0100, Peter Eisentraut wrote:
Am Mittwoch, 20. Dezember 2006 04:44 schrieb Tom Lane:
If you can show me a reasonably bulletproof or machine-checkable way to
keep the two kinds of column
Am Mittwoch, 20. Dezember 2006 14:20 schrieb Kenneth Marshall:
On Wed, Dec 20, 2006 at 01:26:59PM +0100, Peter Eisentraut wrote:
Am Mittwoch, 20. Dezember 2006 04:44 schrieb Tom Lane:
If you can show me a reasonably bulletproof or machine-checkable way to
keep the two kinds of column
Martijn van Oosterhout wrote:
On Wed, Dec 20, 2006 at 07:20:14AM -0600, Kenneth Marshall wrote:
On Wed, Dec 20, 2006 at 01:26:59PM +0100, Peter Eisentraut wrote:
Am Mittwoch, 20. Dezember 2006 04:44 schrieb Tom Lane:
If you can show me a reasonably bulletproof or
* Tom Lane ([EMAIL PROTECTED]) wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Force references to go through macros which implement the lookup for the
appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
It doesn't really address
Russell Smith wrote:
Tom Lane wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Force references to go through macros which implement the lookup for
the
appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
It doesn't really
On Wed, Dec 20, 2006 at 01:26:59PM +0100, Peter Eisentraut wrote:
Am Mittwoch, 20. Dezember 2006 04:44 schrieb Tom Lane:
If you can show me a reasonably bulletproof or machine-checkable way to
keep the two kinds of column numbers distinct, I'd be all for it.
The only way I can see is to
* Andrew Dunstan ([EMAIL PROTECTED]) wrote:
This isn't really a compromise. Remember that this discussion started
with consideration of optimal record layout (minimising space use by
reducing or eliminating alignment padding). The above proposal really
does nothing for that.
While I agree
Andrew Dunstan wrote:
Or we could divide the positive number space in two, by starting at 2^14
(attnums are int2). Then a simple bitmask test would work to distinguish
them.
Perhaps divide-by-four, then it would be possible to have calculated
columns (as mentioned recently on one of the
Bruce Momjian [EMAIL PROTECTED] writes:
I assume space waste will be mostly fixed when we have 0/1 byte headers
for varlena data types.
Hardly. int float timestamp etc types will all still have alignment issues.
regards, tom lane
---(end of
On Wed, Dec 20, 2006 at 09:15:05AM -0500, Stephen Frost wrote:
It doesn't really address the question of how you know which one to
use at any particular line of code; or even more to the point, what
mechanism will warn you if you use the wrong one.
That'd be the point of doing the typing,
Andrew Dunstan wrote:
Russell Smith wrote:
Tom Lane wrote:
Stephen Frost [EMAIL PROTECTED] writes:
Force references to go through macros which implement the lookup
for the
appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
Gregory Stark wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I'm not a big fan of ordering columns to optimise record layout, except in the
most extreme cases (massive DW type apps). I think visible column order should
be logical, not governed by physical considerations.
Well as
On Tue, Dec 19, 2006 at 10:48:41AM -0500, Andrew Dunstan wrote:
Sure, but the only sane way I can think of to do that would be have
separate logical and physical orderings, with a map between the two. I
guess we'd need to see what the potential space savings would be and
establish what the
On Tuesday 19 December 2006 11:25, Martijn van Oosterhout wrote:
On Tue, Dec 19, 2006 at 10:48:41AM -0500, Andrew Dunstan wrote:
Sure, but the only sane way I can think of to do that would be have
separate logical and physical orderings, with a map between the two. I
guess we'd need to see
Robert Treat [EMAIL PROTECTED] writes:
On Tuesday 19 December 2006 11:25, Martijn van Oosterhout wrote:
A patch to allow seperate physical and logical orderings was submitted
and rejected. Unless something has changed on that front, any
discussion in this direction isn't really useful.
The
* Tom Lane ([EMAIL PROTECTED]) wrote:
If you can show me a reasonably bulletproof or machine-checkable way to
keep the two kinds of column numbers distinct, I'd be all for it. But
without that, the answer will remain no.
Force references to go through macros which implement the lookup for the
Stephen Frost [EMAIL PROTECTED] writes:
Force references to go through macros which implement the lookup for the
appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
It doesn't really address the question of how you know which one to
use
39 matches
Mail list logo
