On Tue, 30 Mar 2004, Bruce Momjian wrote:
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
This might seem a bit silly, but is there any chance we could add a
comment at the end of pg_dump text output that says '-- End of dump'?
Sure --- while you're at it, put a
Dear hackers,
I'm still trying to play with pg_catalog relations.
I notice that some tables in pg_catalog have oids, and some do not have
them (e.g. pg_attribute, pg_group, pg_shadow...). Also convenient
user-oriented views could reproduce the oid of their parent table
(e.g. pg_user if
Gavin Sherry [EMAIL PROTECTED] writes:
On Tue, 30 Mar 2004, Bruce Momjian wrote:
I like an end-of-dump marker for folks who want to check if the dump got
truncated somehow. I can see how to do that for text dumps, but what
about for tar or custom dumps?
Wouldn't it be more effective to test
Ok, I just commited changes, pls, check it on HPPA.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
Gavin Sherry wrote:
On Tue, 30 Mar 2004, Bruce Momjian wrote:
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
This might seem a bit silly, but is there any chance we could add a
comment at the end of pg_dump text output that says '-- End of dump'?
Sure ---
Tom Lane wrote:
We have a number of issues revolving around the fact that composite types
(row types) aren't first-class objects. I think it's past time to fix
that. Here are some notes about doing it. I am not sure all these ideas
are fully-baked ... comments appreciated.
[snip]
Only
I added a mention of how to use the pager to lookup datatype mentions in
psql \df:
To look up functions taking argument or returning values of a specific
type, use your pager's search capability to scroll through the
\df output.
No one could come up with a good API to
I have applied a patch to fix the issues mentioned below. Thanks.
---
Karel Zak wrote:
On Fri, Dec 19, 2003 at 01:12:08AM -0800, Dann Corbit wrote:
There is no zero calendar year. The first year of Anno Domini is 1.
Hi
Could someone please try and explain why the cost estimator for the hash
is implemented as it is? (cost_hashjoin in costsize.c)
Especially these issues:
First, there is the estimation on the number of rows and their size.
ExecChooseHashTableSize() apparently trusts neither and doubles them.
Tom,
We have a number of issues revolving around the fact that composite types
(row types) aren't first-class objects. I think it's past time to fix
that. Here are some notes about doing it. I am not sure all these ideas
are fully-baked ... comments appreciated.
I'll want to add to the
Hello,
I'm trying to insert new row in a system catalog table and then I'd like
to retrieve this value in one command internally. I started new
transaction for insertion operation and commited that transaction. And
insert operation works well, but I give me server crash error. Could you
let me
Fabien COELHO [EMAIL PROTECTED] writes:
I notice that some tables in pg_catalog have oids, and some do not have
them (e.g. pg_attribute, pg_group, pg_shadow...).
That's not a bug, it's a feature. We don't use up OIDs on tables that
don't need them.
regards, tom lane
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Only named composite types, not RECORD, will be allowed to be used as
table column types.
Interesting. I'm slightly curious to know if there's an external driver
for this.
There's noplace to store a permanent record of an anonymous
I've been seeing 2 regression failures (diff attached) for the past
couple of days. Both appear to be ordering related.
Joe
regression.diffs.gz
Description: GNU Zip compressed data
---(end of broadcast)---
TIP 7: don't forget to increase your
Joe,
First off, pardon me if these are known things which are already fixed in CVS.
Also, let me again thank you for all the work on Arrays in 7.4; I've been
able to tremendously simplify quite a number of procedures in my databases
thanks to the new array support.
Now, the issue:
I'm
On Tue, Mar 30, 2004 at 12:58:31PM -0500, [EMAIL PROTECTED] wrote:
I'm trying to insert new row in a system catalog table and then I'd like
to retrieve this value in one command internally. I started new
transaction for insertion operation and commited that transaction. And
insert operation
A brief update on PITR status:
I've completed successful unit testing of the PostgreSQL client-side
code for the XLogArchive API. Just about to start moving on to pg_arch
and the archiver side code. At this rate, I should have a
system-testable set of patches in around 2 weeks time for the first
Thank you. At the first time, it works well. But if I try to do same
command again, it still give me a server crash error.
On Tue, Mar 30, 2004 at 12:58:31PM -0500, [EMAIL PROTECTED] wrote:
I'm trying to insert new row in a system catalog table and then I'd like
to retrieve this value in one
Joe Conway [EMAIL PROTECTED] writes:
I've been seeing 2 regression failures (diff attached) for the past
couple of days. Both appear to be ordering related.
Yeah, I'm getting that too. It seems to be a side effect of my fuzzy
cost comparison patch. I've been trying to figure out why I did
I have added this psql backslash discussion to TODO.detail.
---
Peter Eisentraut wrote:
Tom Lane wrote:
But this interacts with point 3 (psql breaks on every new backend
version). It's not desirable to have every GUI
At 12:13 AM 31/03/2004, Bruce Momjian wrote:
Yes, they have to check for a proper exit from pg_dump, but there is
still a file sitting around after the dump, with no way to tell if it is
accurate.
Why don't we write a hash into the header or footer. Then use something like:
pg_restore
I like an end-of-dump marker for folks who want to check if the dump got
truncated somehow. I can see how to do that for text dumps, but what
about for tar or custom dumps?
Wouldn't it be more effective to test for non zero return status as this
handles -Fc cases, etc, which would be non-trivial
Andrew Dunstan wrote:
I wrote:
If nobody is working on this I am prepared to look at it:
. Allow logging of only data definition(DDL), or DDL and modification
statements
Here are some options:
1. change the type of log_statement option from boolean to string,
with
Dear Tom,
I notice that some tables in pg_catalog have oids, and some do not have
them (e.g. pg_attribute, pg_group, pg_shadow...).
That's not a bug, it's a feature. We don't use up OIDs on tables that
don't need them.
Sure. I did not suggest that this is a bug! I'm sorry if it sounded
24 matches
Mail list logo
