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!
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
--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?
--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, i
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
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 like to
--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
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
--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
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, for
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,
seems to me to
Richard Huxton dev@archonet.com 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
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
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
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 that
--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
--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,
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?
Josh Berkus josh@agliodbs.com 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
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 =
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!:
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 gains a
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 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 will
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
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
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 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
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
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
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
'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
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
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
34 matches
Mail list logo
