Andreas Pflug kirjutas N, 20.11.2003 kell 16:10:
Hannu Krosing wrote:
You are just shifting the interface problems to a place needing way more
changes in the backend. There will be some problems either way.
Not quite. Certainly, basing internal storage on attstoragenum is more
We had this discussion. information_schema doesn't deliver enough info
needed for admin tools.
It should. This is the sole reason for existance of it. If it is not
enough, then it should be updated.
It can't. ANSI says only objects owned by the user are shown. Admins
might be quite
Hannu Krosing wrote:
You are just shifting the interface problems to a place needing way more
changes in the backend. There will be some problems either way.
Not quite. Certainly, basing internal storage on attstoragenum is more
work in the backend, but less (precisely: zero) work on an
Andreas Pflug kirjutas N, 20.11.2003 kell 01:38:
Second, column type changes needing a nontrivial cast function should be
implemented in a way that preserve attnum. This could be done like this:
- decompile dependent objects, and memorize them for later recreation
- ADD tmpCol, UPDATE
Hannu Krosing wrote:
attnum is used internally to retrieve the data
Oops...
So if an additional column number is invented, it should not be a
logical column number, but a physical storage number for internal data
retrieval. This way, the user interface doesn't change, and all those
Which is what started the whole discussion.
Dave
On Thu, 2003-11-20 at 04:40, Andreas Pflug wrote:
Hannu Krosing wrote:
attnum is used internally to retrieve the data
Oops...
So if an additional column number is invented, it should not be a
logical column number, but a
Andreas Pflug kirjutas N, 20.11.2003 kell 11:40:
Hannu Krosing wrote:
attnum is used internally to retrieve the data
Oops...
So if an additional column number is invented, it should not be a
logical column number, but a physical storage number for internal data
retrieval.
Hannu Krosing [EMAIL PROTECTED] writes:
You are just shifting the interface problems to a place needing way more
changes in the backend. There will be some problems either way.
Exactly. I'm considerably more worried about breaking out-of-the-way
places in the backend than I am about what order
Tom Lane writes:
Exactly. I'm considerably more worried about breaking out-of-the-way
places in the backend than I am about what order someone's admin tool
presents the columns in.
Clearly, the effort of adding logical column numbers will consist of
making choices between physical and
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane writes:
Exactly. I'm considerably more worried about breaking out-of-the-way
places in the backend than I am about what order someone's admin tool
presents the columns in.
Clearly, the effort of adding logical column numbers will consist
Hannu Krosing wrote:
To put it differently: a ALTER COLUMN command may never-ever change the
identifier of the column, i.e. attrelid/attnum.
to be even more restirictive: ALTER COLUMN may never-ever change the
type of the column, as this too may break some apps. Nah!
Yeah, and the data
11 matches
Mail list logo
