Tom Lane wrote:
mlw [EMAIL PROTECTED] writes:
Aside from adding %llu to all the %u everywhere an OID is used in a
printf, and any other warnings, are there any other things I should be
specially concerned about?
FE/BE protocol, a/k/a client/server interoperability. Flagging a
Tom Lane wrote:
Horst Herb [EMAIL PROTECTED] writes:
On Tuesday 14 August 2001 02:25, you wrote:
I still think that expanding transaction IDs (XIDs) to 8 bytes is no help.
But what about all of us who need to establish a true long term audit trail?
For us, still the most elegant
Hello, I'm having a problem vacuum a table and I didn't see an answer using
the fts engine.
I have two questions:
1) Is this a big problem, can it be fixed, do I have to dump / restore this
table?
2) I found this problem from my nightly cron driven vacuum -a -z. When it
hits this error the
Oleg Bartunov [EMAIL PROTECTED] writes:
If we decide to release 7.1.3 I'd like to see our patch for
contrib/intarray too.
Which one?
regards, tom lane
---(end of broadcast)---
TIP 3: if posting/reading through Usenet,
Jan Wieck [EMAIL PROTECTED] writes:
And he who needs that kind of long term row identifiers would
be better off with 8-byte sequences anyway - IMNSVHO.
Indeed. I've been looking at switching sequences to be int8, and I see
just one little problem, which is to uphold the promise that
Peter Eisentraut [EMAIL PROTECTED] writes:
create function rtest_viewfunc1(int4) returns int4 as
'select count(*) from rtest_view2 where a = $1'
language 'sql';
+ ERROR: return type mismatch in function: declared to return integer, returns
bigint
Maybe instead of testing for strict
Bruce Momjian [EMAIL PROTECTED] writes:
I vote for ignore. Don't tons of projects have a config.h file?
That's exactly why there's a problem. We are presently part of the
problem, not part of the solution.
But we only search our source and other includes. Who installs a
config.h into
There are currently a bunch of items on the Todo relating to SQL
INSERT statements, one of which is allowing INSERTs of the following
form:
INSERT INTO tab [(c1, c2, ...)] VALUES (x1, y1, ...), (x2, y2, ...), ...
I had written a quick 'n dirty patch that accomplished this by
splitting an INSERT
Liam Stewart [EMAIL PROTECTED] writes:
While it
should be possible to modify the Result node to handle multiple
tuples, I would rather not use Result as Result is also used for
constant qualifications.
If you don't want to extend Result, I'd suggest generating a plan that
is an Append of
[Forward to pgsql-announce if appropriate. --Dave]
Alright, I have gone ahead and posted what I have to date regarding the port
of Bugzilla to PostgreSQL that I have been working on. Give it a try and let
me know what I can improve on and what you think. It is dependent on version
7.1.2 of
Tom Lane wrote:
[clip]
This would work, I think, but my goodness it's an ugly solution.
Has any hacker got a better one?
regards, tom lane
How about:
#ifdef INT64_IS_BUSTED
#define int64aligned(name) int32 name##_; int64 name
#else
#define int64aligned(name) int64
Joe Conway [EMAIL PROTECTED] writes:
What I need is a way to pad the struct declaration so that it leaves
8 bytes per int64 column, no matter what. I thought of
What if you defined int64 as a union made up of one long int member and
one 8 byte char member, and then always refer to the long
Serguei Mokhov [EMAIL PROTECTED] writes:
This would work, I think, but my goodness it's an ugly solution.
Is anything wrong with just having two int32 per value for this case?
Well, we do want it to be int64 on machines where int64 is properly
defined. Or are you suggesting
#ifdef
I have a custom datatype (the PostGIS geometry type), which I have
indexed using a GiST index.
The problem is, its difficult to get PostgreSQL to actually use the GiST
index. The only way I can get it to be used is by 'set enable_seqscan =
off', which seems a bit cheezy. What am I missing? Do
On Tue, 14 Aug 2001, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
And he who needs that kind of long term row identifiers would
be better off with 8-byte sequences anyway - IMNSVHO.
What I need is a way to pad the struct declaration so that it leaves
8 bytes per int64
let me know once you are complete, and i'll wrap her up ...
On Tue, 14 Aug 2001, Bruce Momjian wrote:
I will get on this today.
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
That's a couple of days ago now... anything happening?
Bruce is evidently waiting on
On Tuesday 07 August 2001 14:56, Tom Lane wrote:
Ok. This is the second time I have seen this message -- but this one is
delayed by a week. Marc?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
---(end of broadcast)---
TIP 3: if posting/reading
typedef struct FormData_pg_sequence
{
NameData sequence_name;
int32 last_value;
int32 increment_by;
int32 max_value;
int32 min_value;
int32 cache_value;
int32 log_cnt;
char is_cycled;
char is_called;
} FormData_pg_sequence;
If I just change int32 to int64 here, all is well on
Neil Tiffin wrote:
I have not even considered multiple database servers running different
database, which is our design goal. In this case we would like to have
a slimmed down (and blazingly fast) PostgreSQL server in which we manage
the uid in our middleware. This is because the uid
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
Sent: Tuesday, August 14, 2001 10:09 AM
typedef struct FormData_pg_sequence
{
NameData sequence_name;
int64 last_value;
#ifdef INT64_IS_BUSTED
int32 pad1;
[snip]
} FormData_pg_sequence;
This would work, I think, but my
Peter Eisentraut [EMAIL PROTECTED] writes:
create function rtest_viewfunc1(int4) returns int4 as
'select count(*) from rtest_view2 where a = $1'
language 'sql';
+ ERROR: return type mismatch in function: declared to return integer, returns
bigint
Maybe instead of testing for strict
Dave Blasby [EMAIL PROTECTED] writes:
I have a custom datatype (the PostGIS geometry type), which I have
indexed using a GiST index.
The problem is, its difficult to get PostgreSQL to actually use the GiST
index. The only way I can get it to be used is by 'set enable_seqscan =
off', which
Paul Ramsey writes:
Perhaps we could back up at this point and revisit 'contrib' ... at what
point in the size/licence/redundace spectrum do we become reasonable
candidates for 'contrib', if ever? The current tenor seems to be that at
600K/GPL/point-line-polygon we are too big/too
Peter Eisentraut [EMAIL PROTECTED] writes:
What I had in mind was to allow type conversion between the same
TypeCategory(). The SQL function analyzer is extraordinarily picky:
I just finished looking at that. It'd be possible (and probably
reasonable) to accept a binary-compatible datatype
Tom Lane writes:
We could try to force-convert the result of an SQL function to the right
thing, I suppose, but I'm worried that that might mask programmer errors
more than it helps.
What I had in mind was to allow type conversion between the same
TypeCategory(). The SQL function analyzer
Jan Wieck [EMAIL PROTECTED] writes:
What I'm asking myself all the time is which platforms do we
support that doesn't have 8-byte integers?. Could someone
enlighten me please?
Release a version that doesn't work without 8-byte ints, and I'm sure
we'll find out soon enough ;-).
Hello all!!!
I need to retrieve all the users from a group, for my Delphi
Interface for PostgreSQL.
The problem is, I can't accomplish a query that does it, since the
users belonging from a group are all stored in an array field
(pg_group.groulist).
Does anyone have a
Stephan Szabo wrote:
On Tue, 14 Aug 2001, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
And he who needs that kind of long term row identifiers would
be better off with 8-byte sequences anyway - IMNSVHO.
What I need is a way to pad the struct declaration so that it
Tom Lane writes:
This is true in theory, but in practice we've not seen very many
complaints about it; perhaps that's because there's a fair amount of
standardization of Autoconf usage. (HAVE_FOO_H probably gets set the
same way by every package that might use it, for example.)
Agreed in
Tom Lane writes:
I started working on this, and immediately got a pile of regression test
failures arising from:
create function rtest_viewfunc1(int4) returns int4 as
'select count(*) from rtest_view2 where a = $1'
language 'sql';
+ ERROR: return type mismatch in
mlw writes:
I am thinking about embarking on changing the typedef of OID to unsigned long
long.
Aside from adding %llu to all the %u everywhere an OID is used in a printf, and
any other warnings, are there any other things I should be specially concerned
about?
You can start with my patch
- Original Message -
From: Tom Lane [EMAIL PROTECTED]
Sent: Tuesday, August 14, 2001 11:28 AM
Serguei Mokhov [EMAIL PROTECTED] writes:
This would work, I think, but my goodness it's an ugly solution.
Is anything wrong with just having two int32 per value for this case?
Well,
Matthew T. O'Connor [EMAIL PROTECTED] writes:
cms_beau=# vacuum hits; (It works without the analyze phase of backup.)
VACUUM
cms_beau=# VACUUM verbose analyze hits;
NOTICE: --Relation hits--
NOTICE: Pages 8389: Changed 0, reaped 2, Empty 0, New 0; Tup 834575: Vac 0,
Keep/VTL 4/4, Crash
I will get on this today.
[EMAIL PROTECTED] (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=) writes:
That's a couple of days ago now... anything happening?
Bruce is evidently waiting on Hiroshi's confirmation that he's done
applying his back-patches. I believe he is, though; he did apply
Larry Rosenman writes:
I made the following patch, and it works for MY platform.
Peter,
Can we do something similar for the distribution to set the
RUNPATH for Pg.so?
This is an interesting idea. I'd rather rip out MakeMaker completely, but
this might be a good start.
--
Peter
I have to fix my old fault in TID handling.
I am able to have a cvs access now and would
commit the fix to 7.1 branch.
Hiroshi, are you done with changes you want in 7.1.3?
Oops I missed your mail sorry. Unfortunately my mail server
is down and I could access pgsql-hackers
On 30 Jul 2001 Tom Lane wrote:
[EMAIL PROTECTED] writes:
gcc2.95; hppa2.0-hp-hpux10.20, postgresql 7.1.2
make check checks the first group all right (tests check out ok and
a process postgres: shows up in the process list.
When make check displays parallel group (18 tests): point
* Peter Eisentraut [EMAIL PROTECTED] [010814 16:58]:
Larry Rosenman writes:
I made the following patch, and it works for MY platform.
Peter,
Can we do something similar for the distribution to set the
RUNPATH for Pg.so?
This is an interesting idea. I'd rather rip out
Note also that there is code in there to figure out whether a targetlist
satisfies a tuple return datatype; should we also apply automatic type
conversion to elements of such a list? It's getting to be more of a
stretch to say that this is being helpful rather than masking programmer
error.
Peter Eisentraut wrote:
Projects that are as organized, professional, and value-adding as yours is
can surely stand on their own. I compare this to the recently released
OpenFTS. If we start including projects of this size we'd explode in size
and maintenance overhead.
Fair enough...
The Register has an interesting interview with the vp of Microsoft's SQL
Server team:
http://www.theregister.co.uk/content/53/21003.html
Near the end he gets specifically asked about Red Hat Database as a
competitive threat, and he responds that he doesn't think anyone can match
their
I'm sure that 800 professionals equates to something like 4
developers, 1 tester (part-time), 2 documentation specialist, and 792
marketing, sales, administration, legal staff and others required to
justify its cost, and 1 CEO who has his fingers into everything at MS.
Tim Allen wrote:
The
Tim Allen [EMAIL PROTECTED] writes:
Near the end he gets specifically asked about Red Hat Database as a
competitive threat, and he responds that he doesn't think anyone can match
their investment of 800 professionals to work on SQL Server.
ROTFL ...
The longer that Oracle, MS, et al don't
What is OLAP and why is it so good? (According to MS)
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Allen
Sent: Wednesday, 15 August 2001 8:50 AM
To: [EMAIL PROTECTED]
Subject: [HACKERS] MS interview
The Register has an
OLAP Council White Paper
Introduction
The purpose of the paper that follows is to define On-Line
Analytical Processing (OLAP), who uses it and why, and to review
the key features required for OLAP software as referenced in the
OLAP Council benchmark specification.
The longer that Oracle, MS, et al don't believe we're a threat, the
better. But I wonder how they *really* see us. This article was
too obviously a pile of marketing BS to be taken seriously by
anyone.
Not necessarily - business guys are incredibly naive when it comes to
technology
Hopefully, RedHat's involvement will boost the mindshare and image of
PostgreSQL and I don't have to keep doing Oracle admin :)
We had four articles in one day today. That shows some major momentum.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED]
47 matches
Mail list logo
