Hi All,
I've been thinking about this DROP COLUMN business (sorry to start another
spammy, flamey thread!). I'm taking ideas from lots of sources here.
How does this sound for a process?
1.
A new column is added to pg_attribute called 'attisdropped'. It, of course,
defaults to false.
2.
The
Hi Florian,
The most recent patches were submitted by me, so I guess you
could call me
the defacto maintainer.
Okay - glad someone answered me :)
Actually, I replied to you 5 minutes after you posted, but I think my emails
were being stalled somewhere...
I will - please give me a few
2.
The column expansion (*) code and the code that checks for valid column
references everywhere in the codebase is changed to also check the
attisdropped field. Does someone have a comprehensive list of
places to be
changed?
Actually - did Hiroshi(?)'s original HACK have this code - we
On Mon, 2002-07-01 at 09:47, Christopher Kings-Lynne wrote:
Hi All,
I've been thinking about this DROP COLUMN business (sorry to start another
spammy, flamey thread!). I'm taking ideas from lots of sources here.
How does this sound for a process?
1.
A new column is added to
We have been discussing heap tuple header changes for a while now.
Here is my proposal for omitting the oid, when it is not needed:
First let's eliminate t_oid from HeapTupleHeaderData.
Then add the oid to the end of the structure, if and only if it is
needed. The tricky part here is that
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Good idea. Is there a locale-aware version of isalpha anywhere?
If there is - I couldn't find it. I did find a lot of frustated
posts about isalpha and locale-awareness although.
Yeah, I can't find anything in the man pages either. Maybe
Hannu Krosing [EMAIL PROTECTED] writes:
The DROP COLUMN command does nothing but set the attisdropped of a column to
true,
This will probably require a full lock on system tables to avoid nasty
border conditions when updating caches.
AFAICS it's no different from any other ALTER TABLE
Hi.
Huh? isalpha() *is* locale-aware according to the ANSI C spec.
For instance, the attached test program finds 52 alpha characters
in C locale and 114 in fr_FR locale under HPUX.
I am not at all sure that this aspect of Florian's change is a good
idea, as it appears to eliminate
Florian Helmberger [EMAIL PROTECTED] writes:
Just tried your example - you're right of course! I will remove the hard
coded delimited list and replace it with the proper calls as shown in the
code you've sent.
Well, that was a quick hack not clean code. Coding rules for stuff
inside the
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
I think that creating a new function, called ftia or ftix or something is
the best solution. I think I can handle doing that...
Why change the name? If it's got a different argument list then you
can just overload the same old name.
Curt Sampson wrote:
On Fri, 28 Jun 2002, Bruce Momjian wrote:
OK, we need to vote on this patch. It reduces the tuple header by 4
bytes (11% decrease).
If we apply it, we will not be able to easily use pg_upgrade for 7.3
because the on-disk table format will change.
Votes are:
Manfred Koizar [EMAIL PROTECTED] writes:
. Does heap_addheader *always* create a header with oid?
No.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
On Mon, 01 Jul 2002 12:40:35 +0200, I wrote:
Bytes saved on architectures with 4/8 byte alignment:
hoffbytes
natts bitmaplen hoff72 oidoff woosaved
0 28/32 2424/244/8
1-81 28/32 2424/244/8
9-40
Manfred Koizar [EMAIL PROTECTED] writes:
Here is my proposal for omitting the oid, when it is not needed:
I do not think you can make this work unless has oids is added to
TupleDescs. There are too many places where tuples are manipulated
with only a tupdesc for reference.
It might also be
I am not at all sure that this aspect of Florian's change is a good
idea, as it appears to eliminate locale-awareness in favor of a hard
coded delimiter list.
Just tried your example - you're right of course! I will remove the hard
coded delimited list and replace it with the proper
This part should fall out of Rod Taylor's pg_depend stuff pretty easily.
We still need to debate about the behavior, though. If for example there
is a unique index on column B, do you need DROP B CASCADE to get rid
of it, or is DROP B RESTRICT good enough? Does your answer change if
the
George,
I like your updated version and have put it on my site.
Are you willing to contribute some examples and test data,
so we (me, Teodor and you) could arrange separate page for this module.
As I wrote, we'll continue developing and you're welcome.
Oleg
On Sun, 30 Jun 2002, George
Hi,
Has anyone considered creating an aggregate function that returns an
array of all matching rows? I am not sure if this makes much sense from
a speed point of view or is possible, but it would help denormalizing
tables when necessary. For example, consider a table that looks as follows:
On Wednesday 26 June 2002 11:48 pm, Christopher Kings-Lynne wrote:
I suggest that pgAdmin is included in the install process. Imagine it - a
win32 person downloads a single .exe, with contents bzip2'd. They run the
installer, it asks them to agree to license, shows splash screen, asks them
Manfred Koizar [EMAIL PROTECTED] writes:
... I wonder
whether we shouldn't apply this second version (without the configure
parts) and put all forthcoming format changes under #ifndef
PG72FORMAT.
Seems reasonable. I generally dislike #ifdef clutter, but the #ifs
would only be around a
It would all work out of the box and would do wonderful things for the
Postgres community.
I like this idea, but let me just bring one little issue to note: are you
going to handle upgrades, and if so, how? How are you going to
do a major
version upgrade?
Well, the easiest way would be
How does the upgrade work on UNIX? Is there anything available apart from
reading the release note?
- Original Message -
From: Christopher Kings-Lynne [EMAIL PROTECTED]
To: Lamar Owen [EMAIL PROTECTED]; Jan Wieck [EMAIL PROTECTED];
HACKERS [EMAIL PROTECTED]
Sent: Tuesday, July 02, 2002
OK,
On HEAD, I am still seeing the attached failures. They didn't happen
before, but appeared in the last couple of months. All other tests pass.
It seems to just be a tuple ordering issue - I really don't know what caused
it? If necessary, I can just modify the expected result, but I
I was getting CVS errors because regress/GNUmakefile does an 'rm -rf
results', removing the CVS directory from results. This was causing my
'cvs update's to fail. My fix was to change 'rm -rf results' to 'rm -f
results/*.out'.
Does anyone know when this problem was added. I don't see any
pgman wrote:
I was getting CVS errors because regress/GNUmakefile does an 'rm -rf
results', removing the CVS directory from results. This was causing my
'cvs update's to fail. My fix was to change 'rm -rf results' to 'rm -f
results/*.out'.
Does anyone know when this problem was added. I
25 matches
Mail list logo
