Justin Clift wrote:
Hi guys,
Have created a Solaris 8 Intel package for PostgreSQL 7.3.1, but don't
have any SPARC boxes here any more.
Does anyone have a SPARC box handy that would be available for
compiling PostgreSQL 7.3.1 on? It would need to be Solaris 8 (or
maybe 9), and have things
On 14 Jan 2003 10:54:29 -0500, Robert Treat
[EMAIL PROTECTED] wrote:
Changed = the number of pages that had to be modified.
This counts only pages changed due to heap tuple header updates
(FrozenTransactionId, hint bits). It does not count page changes due
to removal of dead tuples, cf. Julian's
Mark Kirkwood wrote:
snip
I can get access to several boxes with Solaris 8 + gcc 2.95 ( maybe not
right-up-to-the minute latest patches, but fairly recently patched).
They are firewalled off from the internet with abolutely no chance of
external access, but I can build whatever is required (
Stephan Szabo [EMAIL PROTECTED] writes:
Hmm, I think (but am not sure) that the spec bit
in SQL92 that addresses this is 9.3
Set operation result data types based on the
text in 7.10 query expression. It seems
to say to me that should always be an
approximate numeric (if 1.0 is an
On Wed, 15 Jan 2003, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
Hmm, I think (but am not sure) that the spec bit
in SQL92 that addresses this is 9.3
Set operation result data types based on the
text in 7.10 query expression. It seems
to say to me that should always be an
Stephan Szabo [EMAIL PROTECTED] writes:
It seems to me that the spec has a fairly hardwired notion of what types
should come out given the sql types. The biggest problems that I can
see are that it doesn't extend well to an extensible type system and that
in alot of cases it doesn't seem to
Looks like some ORDER BY statements would be useful.
*** ./expected/inet.out Sat Jun 16 22:05:20 2001
--- ./results/inet.out Wed Jan 15 10:18:40 2003
***
*** 193,212
select * from inet_tbl where i'192.168.1.0/24'::cidr;
c|i
On Wednesday 15 January 2003 09:20, Justin Clift wrote:
Sound like a plan? Will also need someone else with a Solaris 8 SPARC
system to try the packages out too, just in case there are weird library
dependencies happening that might catch us out.
I have access to several (two dozen) currently
On Wed, 15 Jan 2003, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
It seems to me that the spec has a fairly hardwired notion of what types
should come out given the sql types. The biggest problems that I can
see are that it doesn't extend well to an extensible type system and
OK, I have applied an patch to ORDER BY on those queries. I don't see
the ordering you have here, but this should fix it for you. I also
uppercased the keywords while I was in there.
---
Rod Taylor wrote:
-- Start of PGP
Lamar Owen wrote:
On Wednesday 15 January 2003 09:20, Justin Clift wrote:
Sound like a plan? Will also need someone else with a Solaris 8 SPARC
system to try the packages out too, just in case there are weird library
dependencies happening that might catch us out.
I have access to
THe SQL Flagger is only required for Intermediate SQL. SQL'92 23.4 says Entry
SQL may, but are not required to.
This said, it is a nice to have feature for the reasons that Peter pointed out.
But as I understand it, this is a sort of warning feature, and depending on the
extent of checking
Tom Lane wrote:
Ian Barwick [EMAIL PROTECTED] writes:
On Sunday 12 January 2003 17:55, Bruce Momjian wrote:
I can't say don't use CHAR(n) because there are valid reasons to use
it.
I think what Tom is saying is always use VARCHAR(n) unless you know
for sure CHAR(n) is what you want,
Christopher Kings-Lynne writes:
We have roles?
Until two days ago I was under the impression that roles were schema
objects, but apparently this is not the case, and it seems that roles are
really just an extension of our group concept.
--
Peter Eisentraut [EMAIL PROTECTED]
Lamar Owen wrote:
On Wednesday 15 January 2003 09:20, Justin Clift wrote:
Sound like a plan? Will also need someone else with a Solaris 8 SPARC
system to try the packages out too, just in case there are weird library
dependencies happening that might catch us out.
I have access to several
Justin Clift writes:
Also, am wondering if learning how to do cross compiling instead might
be worthwhile. Don't yet know anything about it, but it gets mentioned
in a lot of documents.
The hard part about cross-compiling is getting a cross-compiler
(especially if you have to build it
I just wanted to post this note.
I have been in Oracle hell for four days now, and in between the 5
minutes of work and the hours of watings, dealing with table spaces,
extents, and all that, I just keep thinking about how much easier
PostgreSQL is to work with.
We all may bitch and moan
On Wed, 15 Jan 2003, mlw wrote:
I just wanted to post this note.
I have been in Oracle hell for four days now, and in between the 5
minutes of work and the hours of watings, dealing with table spaces,
extents, and all that, I just keep thinking about how much easier
PostgreSQL is to
Gavin Sherry wrote:
On Wed, 15 Jan 2003, mlw wrote:
I just wanted to post this note.
I have been in Oracle hell for four days now, and in between the 5
minutes of work and the hours of watings, dealing with table spaces,
extents, and all that, I just keep thinking about how
Rod Taylor [EMAIL PROTECTED] writes:
Looks like some ORDER BY statements would be useful.
To do what? Those queries should already be producing indexscan plans.
If you're not getting the expected answers, there is something that
needs to be fixed, not papered over.
Please try
create index
If you get it working, I can remove the ORDER BY's I added.
---
Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
Looks like some ORDER BY statements would be useful.
To do what? Those queries should already be
snippage
The Oracle system stops from time to time because of various arcane
reasons. You get the error message, look it up on alltheweb.com, and
fix it. The whole system is bogus. It DEMANDS a full time DBA.
PostgreSQL does not.
I could be accused of being cynical here (gosh)... but I
regression=#
regression=#
regression=# create index inet_idx1 on inet_tbl(i);
CREATE INDEX
regression=# set enable_seqscan to off;
SET
regression=# explain select * from inet_tbl where
i'192.168.1.0/24'::cidr;
QUERY
PLAN
With Bruce's patch came a few others -- plus a recompile with all
updates.
... and that's the expected result. So why'd you get a different result
while running the regression test? Curiouser and curiouser...
--
Rod Taylor [EMAIL PROTECTED]
PGP Key: http://www.rbt.ca/rbtpub.asc
On Wed, 2003-01-15 at 15:29, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
With Bruce's patch came a few others -- plus a recompile with all
updates.
Which patch exactly? The regression test was still passing for me
as of yesterday's sources plus the large planner commit I just
Rod Taylor [EMAIL PROTECTED] writes:
With Bruce's patch came a few others -- plus a recompile with all
updates.
Which patch exactly? The regression test was still passing for me
as of yesterday's sources plus the large planner commit I just made.
I'm resyncing to CVS tip at the moment ...
Rod Taylor [EMAIL PROTECTED] writes:
Index Scan using inet_idx1 on inet_tbl (cost=3D0.00..4.68 rows=3D7
width=3D64)
Index Cond: ((i '192.168.1.0/24'::inet) AND (i =3D
'192.168.1.255'::inet))
Filter: (i '192.168.1.0/24'::inet)
(3 rows)
That's the expected plan ...
regression=3D#
Rod Taylor [EMAIL PROTECTED] writes:
Last update was about 5 minutes after Bruce's header fix went into
place.
Hm. I just finished verifying that CVS tip builds and passes cleanly
on both HPUX and Linux (Red Hat 8.0). So either you've got a build
error (did you do a make clean after your last
On Wed, 2003-01-15 at 16:07, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
Last update was about 5 minutes after Bruce's header fix went into
place.
Hm. I just finished verifying that CVS tip builds and passes cleanly
on both HPUX and Linux (Red Hat 8.0). So either you've got a
Rod Taylor [EMAIL PROTECTED] writes:
On Wed, 2003-01-15 at 16:07, Tom Lane wrote:
Hm. I just finished verifying that CVS tip builds and passes cleanly
on both HPUX and Linux (Red Hat 8.0). So either you've got a build
error (did you do a make clean after your last update?) or there's
some
Eric B.Ridge writes:
What about expanding the history capabilities of psql's history command
(\s) to include something more bash/tcsh-like? For example:
!insert
-- execute the last command that began with insert
!23
-- execute item #23 in my history
If you peruse the
Fernando Nasser writes:
THe SQL Flagger is only required for Intermediate SQL. SQL'92 23.4 says Entry
SQL may, but are not required to.
SQL 92 is obsolete. In SQL 99 and later it's a core feature.
If I understood it correctly, we only need a new elog level and add a few elog
calls in some
(i.e. arcane
little need to know things that trap all but the initiated...
So, for postgres, that means:
- a good thing the autovacuum thingy is coming along
- postgres should auto-tune itself - the *cost could perhaps be
adjusted after some statistics have been collected, and there should
Adrian 'Dagurashibanipal' von Bidder wrote:
I'm just saying that there are
*some* small arcane details in postgres, too (although, at least, they
don't affect stability, just performance).
Indeed you are right... Pg has its own collection of arcane details too,
but hopefully the culture of
[EMAIL PROTECTED] writes:
Sample Code
create table teste(serie integer,aula text[][]);
//it´s ok when insert this
insert into teste values (1,'{{004,009},{009},{},
{001,002}}');
//But when I insert this..
insert into teste values
(1,'{{004,009,002},{009,001},{},{001,002}}');
Hm. I just finished verifying that CVS tip builds and passes cleanly
on both HPUX and Linux (Red Hat 8.0). So either you've got a build
error (did you do a make clean after your last update?) or there's
some really weird platform dependency involved. What's your platform
again?
I
On Wed, 2003-01-15 at 20:15, Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
On Wed, 2003-01-15 at 16:07, Tom Lane wrote:
Hm. I just finished verifying that CVS tip builds and passes cleanly
on both HPUX and Linux (Red Hat 8.0). So either you've got a build
error (did you do a make
37 matches
Mail list logo
