Patch applied. Thanks.
---
Manfred Koizar wrote:
> On Mon, 24 Jun 2002 12:53:42 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
> >the extra level of struct naming for pd_opaque has no obvious
> >usefulness.
> >
> >> [...] sh
Tom Lane wrote:
> 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 th
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 adde
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
signi
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 haven't
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, J
> > 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
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:
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
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
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 Es
On Mon, 1 Jul 2002 10:15:42 -0400 (EDT), Bruce Momjian
<[EMAIL PROTECTED]> wrote:
>OK, I have heard enough votes to add this.
In a second version of this patch posted on 2002-06-26 you can control
the tuple format by #define/#undef PG72FORMAT. While there have been
voices saying that exposing th
> 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
> > 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 pro
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 b
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-4
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]
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.
> >
>
"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.
"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 th
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 lo
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 TAB
"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 eith
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 there
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 p
> 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 -
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 m
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
28 matches
Mail list logo