When i try to compile postgres 8 on windows machine i get this error
after i issue the make command
make -C doc all
make[1]: Entering directory `/src/pgsql/doc'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/src/pgsql/doc'
make -C src all
make[1]: Entering directory `/src
Edmund Dengler <[EMAIL PROTECTED]> writes:
> Is there an issue when a large number of INHERITS tables exist for
> planning?
Well, there are a number of issues whenever a single query references
a whole lot of tables in any fashion. It's only with Neil Conway's
rewrite of the List package in 8.0 t
Someone commented to me recently that they usually use psql's \x
"expanded output" mode, but find that it produces pretty illegible
results for psql slash commands such as \d. I can't really see a reason
you would _want_ "expanded output" mode for the result sets of psql
slash commands. Would a
Someone commented to me recently that they usually use psql's \x
"expanded output" mode, but find that it produces pretty illegible
results for psql slash commands such as \d. I can't really see a reason
you would _want_ "expanded output" mode for the result sets of psql
slash commands. Would a
'k, is the bug with pg_dump, or pg_restore? I'm guessing pg_dump, but
just want to make sure ...
Yeah it is an ordering problem with pg_dump...
The bug is in pg_dump and isn't fixed until 8.0.
Chris
---(end of broadcast)---
TIP 7: don't forge
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm not real thrilled with the notion of trying to use a zic built by
>> a different compiler; I think that will lead to all sorts of
>> problems, considering that the files it's meant to write are binary
>> and at least potentially
I propose the attached patch as a poor fix for the cross-compilation
problems. It doesn't really solve anything but prints out a message to
let cross-compiling folks know that they need to fix up the
installation themselves.
Comments?
--
Peter Eisentraut
http://developer.postgresql.org/~pete
Tom Lane wrote:
> I'm not real thrilled with the notion of trying to use a zic built by
> a different compiler; I think that will lead to all sorts of
> problems, considering that the files it's meant to write are binary
> and at least potentially architecture-specific.
Btw., in light of that the
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Yeah it is an ordering problem with pg_dump...
If you are using pg_restore you can hack around the problem by using
pg_restore's load-order-control switch (which was invented exactly to
let people work around pg_dump's problems ;-)). In this case th
Yes that bug definately exists in 7.4 we have had multiple problems
with it. I do believe it is fixed in the 8 series though.
'k, is the bug with pg_dump, or pg_restore? I'm guessing pg_dump, but
just want to make sure ...
Yeah it is an ordering problem with pg_dump...
Sincerely,
Joshua
On Thu, 9 Jun 2005, Joshua D. Drake wrote:
This is with pg_restore from 7.4.6 ... so this might be something that has
been fixed already ... but figured I'd make sure it wasn't just me doing
something wrong ...
Yes that bug definately exists in 7.4 we have had multiple problems with it.
I
This is with pg_restore from 7.4.6 ... so this might be something that
has been fixed already ... but figured I'd make sure it wasn't just me
doing something wrong ...
Yes that bug definately exists in 7.4 we have had multiple problems with
it. I do believe it is fixed in the 8 series though
I thought it was supposed to know "proper ordering" for doing the restore,
but:
%bin/pg_restore -d data ../db/data.dump | & tee data.data.log
pg_restore: NOTICE: CREATE TABLE will create implicit sequence "resellers_id_seq" for
"serial" column "resellers.id"
pg_restore: NOTICE: CREATE TABLE
Marc G. Fournier wrote:
> Sweet, that's it ... could you add an EXAMPLE section to the man page
> showing this? Seems I'm not the only one that was a bit confused how
> to use it, based on other 'try this' that ppl sent :)
Done.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
> > I'd say that's an improvement worth having, especially considering that
> > it requires no net expenditure of CPU time. But the table is certainly
> > still open to discuss more complicated approaches.
>
> If it's not hard to hack in as a test, it'd be interesting to see what
> additional gai
On Thu, 9 Jun 2005, Josh Berkus wrote:
Marc,
What did I post? *raised eyebrow*
Didn't you grep the source for "GPL"? Or was it someone else?
Someone else :)
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrap
On Sat, Jun 04, 2005 at 11:46:07AM -0400, Tom Lane wrote:
> I've completed a test run for this (it's essentially MySQL's sql-bench
> done immediately after initdb). What I get is:
>
> CVS tip of 6/1: ending WAL offset = 0/A364A780 = 2741282688 bytes written
>
> CVS tip of 6/2: ending WAL offset
Josh Berkus writes:
> Didn't you grep the source for "GPL"? Or was it someone else?
That was me...
regards, tom lane
---(end of broadcast)---
TIP 8: explain analyze is your friend
Marc,
> What did I post? *raised eyebrow*
Didn't you grep the source for "GPL"? Or was it someone else?
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 6: Have you searched our list archives?
--On Donnerstag, Juni 09, 2005 10:17:33 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
Hmm? You're planning to write into the relation in question. It's
hardly likely that the structure can be expected to remain virgin...
in practice I don't think we guarantee that even for read operations.
Oh,
--On Donnerstag, Juni 09, 2005 12:05:45 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
I don't think you have any choice about that --- I'm pretty sure that
there are places that assume a table's indexes are in the same schema
the table is. Constraints ditto.
Okay, then the consenus is to go for
Bernd Helmle <[EMAIL PROTECTED]> writes:
> --On Donnerstag, Juni 09, 2005 21:05:59 +0800 Christopher Kings-Lynne
>> Oh yes, you're probably right. Indexes should move though I think?
> Yes, i think so, too.
I don't think you have any choice about that --- I'm pretty sure that
there are places t
Sweet, that's it ... could you add an EXAMPLE section to the man page
showing this? Seems I'm not the only one that was a bit confused how to
use it, based on other 'try this' that ppl sent :)
On Thu, 9 Jun 2005, Peter Eisentraut wrote:
Marc G. Fournier wrote:
# ./configure `pg_config -
On Wed, 8 Jun 2005, Josh Berkus wrote:
Neil,
I've volunteered to do this in the past, and the response was that it is
something that only members of core are in a position to do this. That
is perfectly reasonable, but that was quite some time ago -- it would be
nice to see some movement on thi
Richard Huxton writes:
> I'm not sure it's sensible to have the update in the WHERE clause - I
> don't know that you can depend on how many times that function will be
> called.
It's absolutely not very sensible to do that ... note the warnings in
http://www.postgresql.org/docs/8.0/static/sql-e
Bernd Helmle <[EMAIL PROTECTED]> writes:
> --On Mittwoch, Juni 08, 2005 14:49:56 -0400 Tom Lane <[EMAIL PROTECTED]>
> wrote:
>> Applying "const" to pointers that point to things that are not const,
>> as in
>>
>> + void
>> + ApplyTypeNamespace( Oid typeOid,
>> +const Relation rel,
Alvaro Herrera wrote:
> On Wed, Jun 08, 2005 at 10:25:18PM -0400, Bruce Momjian wrote:
> >
> > I will post tomorrow on a plan for this.
>
> If you need developer time, I'm available to work on this as it seems
> higher priority to me that shared dependencies.
Yes, I am going to need lots of help
--On Donnerstag, Juni 09, 2005 21:05:59 +0800 Christopher Kings-Lynne
<[EMAIL PROTECTED]> wrote:
Oh yes, you're probably right. Indexes should move though I think?
Yes, i think so, too.
--
Bernd
---(end of broadcast)---
TIP 5: Have you ch
They should all be moved. Remember nasties like indexes should be moved
as well as toast tables.
Oh, i thought toast tables should live in the pg_toast namespace?
Oh yes, you're probably right. Indexes should move though I think?
Chris
---(end of broadcast)
--On Mittwoch, Juni 08, 2005 14:48:55 -0400 Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
On Wed, Jun 08, 2005 at 08:25:12PM +0200, Bernd Helmle wrote:
One issue that comes to my mind is what to do when dealing with tables
that have assigned triggers and sequences (serials). Do we want to move
t
Hi Hannu,
On Thu, Jun 09, 2005 at 01:03:42AM +0300, Hannu Krosing wrote:
> >
> > I was searching for some information about the storage of the user data
> > in postgresql. As far as I know there is one dictionary table for
> > storeing all the users of any known database, right?
> >
> > As we'd
On K, 2005-06-08 at 22:40 +0200, Yann Michel wrote:
> Hi,
>
> I was searching for some information about the storage of the user data
> in postgresql. As far as I know there is one dictionary table for
> storeing all the users of any known database, right?
>
> As we'd like to provide a postgresql
--On Mittwoch, Juni 08, 2005 14:49:56 -0400 Tom Lane <[EMAIL PROTECTED]>
wrote:
The code seems fairly schizoid about whether the operation is an "alter
namespace" or a "rename". Please be consistent. I'd say it is *not*
a rename, but I suppose you could make an argument the other way ...
No
--On Donnerstag, Juni 09, 2005 10:33:08 +0800 Christopher Kings-Lynne
<[EMAIL PROTECTED]> wrote:
One issue that comes to my mind is what to do when dealing with tables
that have assigned triggers and sequences (serials). Do we want to move
them as well or leave them in the source namespace?
T
Yuri B. Lukyanov wrote:
I have table:
and function:
But this thing don't work:
UPDATE test SET text2='test' WHERE id = (SELECT test1());
(rows affected: 0)
Why? There is two updates on the same row, but work only first update
(in the function). Maybe it's bug?
Hmm - PostgreSQL has a tran
On Jun 9, 2005, at 2:35 PM, Tom Lane wrote:
Hm, have you adjusted the size (typlen) shown for "interval" in
pg_type?
(This is of course an initdb-forcing change.)
No, I hadn't. I've done that now (editing pg_type.h and bumping the
typlen from 12 to 16) and it appears to have fixed it! Tha
36 matches
Mail list logo
