Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Oliver Elphick wrote:
Checking application/pg
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Nicolas Bazin wrote:
> Here is the description
Gilles DAROLD wrote:
> Hi Justin,
>
> I have a new updated version of the Ora2Pg tool which correct many
> problems and add some new features, could you or someone else update
> the contrib directory.
> (download at: http://www.samse.fr/GPL/ora2pg/ora2pg-1.8.tar.gz)
Thanks. CVS updated.
> I al
Tom Lane writes:
> PUBLIC is a reserved keyword, so you have to do something like
> select * from "public".vs1;
> if there is a vs1 hiding it in an earlier namespace in the search
> path.
PUBLIC can be made less reserved easily. See patch below.
> I've been vacillating about whether to c
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I can see the content of yamada.vs1 by the command
> > select * from vs1
> > but there seems to be no way to see the content of
> > public.vs1.
>
> PUBLIC is a reserved keyword, so you have to do something like
> select *
Tom Lane wrote:
> PUBLIC is a reserved keyword, so you have to do something like
> select * from "public".vs1;
> if there is a vs1 hiding it in an earlier namespace in the search
> path.
>
> I've been vacillating about whether to choose another name for the
> public namespace to avoid the n
Hi all,
Some questions:
1. What is the difference between abstime and timestamp - they seem to
display equally...
2. Since int4 and abstime are binary compatible (ie int4::abstime works), is
there any serious problem with updating a pg_attribute row for an int4 and
changing it to and abstime?
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Bruce Momjian writes:
> >> If you would prefer LOG down near INFO in the server message levels,
> >> please post the idea and let's get some more comments from folks.
>
> > LOG should be below WARNING, in any case. Perhaps betwee
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>> If you would prefer LOG down near INFO in the server message levels,
>> please post the idea and let's get some more comments from folks.
> LOG should be below WARNING, in any case. Perhaps between NOTICE and
> WARNING, but
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > Bruce Momjian wrote:
> > >
> > > Hiroshi Inoue wrote:
> > > > > > Why should the timeout be reset automatically ?
> > > > >
> > > > > It doesn't need to be reset automatically, but the problem is that if
> > > > > you are doing a timeout for single
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I can see the content of yamada.vs1 by the command
> select * from vs1
> but there seems to be no way to see the content of
> public.vs1.
PUBLIC is a reserved keyword, so you have to do something like
select * from "public".vs1;
if there is a
Bruce Momjian writes:
> If you would prefer LOG down near INFO in the server message levels,
> please post the idea and let's get some more comments from folks.
LOG should be below WARNING, in any case. Perhaps between NOTICE and
WARNING, but I'm not so sure about that.
--
Peter Eisentraut
Hiroshi Inoue wrote:
> Bruce Momjian wrote:
> >
> > Hiroshi Inoue wrote:
> > > > > Why should the timeout be reset automatically ?
> > > >
> > > > It doesn't need to be reset automatically, but the problem is that if
> > > > you are doing a timeout for single statement in a transaction, and that
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > > > Why should the timeout be reset automatically ?
> > >
> > > It doesn't need to be reset automatically, but the problem is that if
> > > you are doing a timeout for single statement in a transaction, and that
> > > statement aborts the transacti
Hiroshi Inoue wrote:
> > > Why should the timeout be reset automatically ?
> >
> > It doesn't need to be reset automatically, but the problem is that if
> > you are doing a timeout for single statement in a transaction, and that
> > statement aborts the transaction, the SET command after it to re
Hi,
I'm playing with the new schema functionality.
I login to a database as a user yamada.
There I created 2 schemas yamada and inoue.
By accident I made 2 tables with the same name
vs1 in both public and yamada schemas.
I can see the content of yamada.vs1 by the command
select * from vs1
but
Bruce Momjian wrote:
>
> > > > The current plan seems to be to make changes in the backend and the JDBC
> > > > interface, the bulk of the implementation being in the backend.
> > >
> > > Yes, ODBC and JDBC need this, and I am sure psql folks will use it too,
> > > not counting libpq and all the o
> > > The current plan seems to be to make changes in the backend and the JDBC
> > > interface, the bulk of the implementation being in the backend.
> >
> > Yes, ODBC and JDBC need this, and I am sure psql folks will use it too,
> > not counting libpq and all the others.
>
> I wasn't able to fol
> > For each page hit, I do this:
> >
> > update pagecounts set counter = counter + 1 where pagename =
> 'testpag.php'
> >
> > Do I have to set a particular isolation level? Or does this not work in
> > general?
>
> In read committed level, if the second update launches before the first
> update
Bruce Momjian wrote:
>
> Jessica Perry Hekman wrote:
> > On Tue, 2 Apr 2002, Barry Lind wrote:
> >
> > > Since both the JDBC and ODBC specs have essentially the same symantics
> > > for this, I would hope this is done in the backend instead of both
> > > interfaces.
> >
> > The current plan seems
Tom Lane wrote:
>
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Tom Lane writes:
> To my mind, full SERIALIZABLE mode is the only approach that can be
> explained in terms of simple notions like "you see only the data that
> existed at time T".
There's another way. If the current value is d
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > > > Server levels are:
> > > >
> > > > # debug5, debug4, debug3, debug2, debug1,
> > > > # info, notice, warning, error, log, fatal, panic
> > >
> > > I don't recall log being so high. Didn't it use to be after i
Tom Lane writes:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > It could also be considered deterministic, strict, cacheable,
> > mathematically sensible, real, pleasant, or good. ;-)
>
> > Out of those, I believe "const" is the worst term, because saying "sin(x)
> > is a constant function" s
Bruce Momjian writes:
> > > Server levels are:
> > >
> > > # debug5, debug4, debug3, debug2, debug1,
> > > # info, notice, warning, error, log, fatal, panic
> >
> > I don't recall log being so high. Didn't it use to be after info?
> > Certainly there should be a way
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > > There doesn't seem to be a way to turn off LOG without hiding almost
> > > everything:
> > >
> > > if (lev == LOG || lev == COMMERROR)
> > > {
> > > if (server_min_messages == LOG)
> > > output_to_server = tru
> FWIW, all the blacklists I use (and 510sg is only the first line of
> defense ;-)) have documentation available about the reasons for listing
> IP blocks. F'r instance, looking up Thomas' IP I get:
...
> But this is getting pretty far off-topic for the PG lists.
I'll guess that the list of rea
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> The reason it works in read-committed mode is that the second guy to
>> arrive at the row will observe that the row has an update in progress;
>> will block waiting for the previous updater to commit or abort; and if
>> commit, wil
Bruce Momjian writes:
> > There doesn't seem to be a way to turn off LOG without hiding almost
> > everything:
> >
> > if (lev == LOG || lev == COMMERROR)
> > {
> > if (server_min_messages == LOG)
> > output_to_server = true;
> > else if (server
Tom Lane writes:
> The reason it works in read-committed mode is that the second guy to
> arrive at the row will observe that the row has an update in progress;
> will block waiting for the previous updater to commit or abort; and if
> commit, will use the updated version of the row as the starti
On Wed, Apr 03, 2002 at 08:45:03AM -0800, Thomas Lockhart wrote:
> ...
> > I'm not sure I'm the only one, am I?
>
> No, I was also blocked from Tom's mail a while ago. I have a static IP,
> but my ISP's entire block of addresses made it on to the spam list Tom
> uses, and the strategy of the list
Tom Lane wrote:
>
> Doug McNaught <[EMAIL PROTECTED]> writes:
> > Actually, the C standard says nothing about what algorithm should be
> > used for qsort(); it's simply supposed to be a fast in-memory sort.
> > The qsort() name is just a historical artifact.
>
> In practice I believe qsort usual
Take this update statement:
update mytable set foo=foo+1 where bar='xxx';
If that gets executed more than once at the same time by multiple instances of
postgresql. Will foo ever lose a count?
I am assumed that foo will always be correct and that the database will manage
any contention, but wh
Mikhail Terekhov <[EMAIL PROTECTED]> writes:
> Why do you think so? Even if you are right and original design was
> just for invalidate-your-cache arrangements, current implementation
> has much more functionality and can be used as a reliable message
> transmission mechanism (we use it that way).
Tom,
I sent a list of items I would like to work on for my Master's Project
yesterday, but didn't hear back. I don't want to be a pest, but was
wondering when you turned on your anti-spam software -- is it possible I got
kicked out and you didn't get my reply?
Thanks,
Mike Shelton
-Origina
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Does anyone know the ramifications of allowing SET to work in an aborted
> transaction?
This is not an option.
The case that will definitely Not Work is SET variables whose setting
or checking requires database accesses. The new search_path variable
c
Tom Lane wrote:
>
> Justin Clift <[EMAIL PROTECTED]> writes:
> > I agree adding an automatic background vacuum thread/process/something
> > will be really, really useful too.
> > Should we instead have this proposed automatic background something also
> > update the statistics every now and again
Tom Lane wrote:
> LISTEN/NOTIFY is basically designed for invalidate-your-cache
> arrangements (which is what led into this discussion originally, no?).
Why do you think so? Even if you are right and original design was
just for invalidate-your-cache arrangements, current implementation
has m
Justin Clift <[EMAIL PROTECTED]> writes:
> I agree adding an automatic background vacuum thread/process/something
> will be really, really useful too.
> Should we instead have this proposed automatic background something also
> update the statistics every now and again?
Yes, I had always assume
> BTW, I still suggest changing initdb to set message_level = FATAL rather
> than /dev/null'ing the output. Having to use -d to learn anything at
> all about the cause of an initdb-time failure is a pain in the neck.
This is a great idea. Certainly there are FATAL/PANIC messages during
initdb t
Peter Eisentraut wrote:
> Tom Lane writes:
>
> > It might be that Bruce's recent changes to elog levels allow a graceful
> > compromise about backend messages during initdb. I haven't looked, but
> > maybe initdb could run the backend with message level one notch higher
> > than LOG to suppress
Tom Lane wrote:
>
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > ... And PostgreSQL needs some frequent VACUUM
> > anyway, so after a while this problem solves itself for the
> > average user.
>
> Yes, that's the key point for me too. Anyone who doesn't set up for
> routine vacu
Gavin Sherry wrote:
> On Wed, 3 Apr 2002, Mikhail Terekhov wrote:
>>
>>Tom Lane wrote:
>>
>>>There is a very significant performance problem with LISTEN/NOTIFY
>>>via pg_listener: in any application that generates notifications at
>>>a significant rate, pg_listener will accumulate dead tuples at
mlw <[EMAIL PROTECTED]> writes:
> I'm not sure you answered my question. Let me put it to you like this:
> Suppose I wanted to make a table of page counts, like this:
> create table pagecounts (counter int4, pagename varchar)
> For each page hit, I do this:
> update pagecounts set counter = counte
Tom Lane wrote:
>
> It occurs to me that we also need a better term for the overall concept.
> "cacheability" has misled at least two people (that I can recall) into
> thinking that we maintain some kind of function result cache --- which
> is not true, and if it were true we'd need the term "cac
Jessica Perry Hekman wrote:
> On Tue, 2 Apr 2002, Barry Lind wrote:
>
> > Since both the JDBC and ODBC specs have essentially the same symantics
> > for this, I would hope this is done in the backend instead of both
> > interfaces.
>
> The current plan seems to be to make changes in the backen
It occurs to me that we also need a better term for the overall concept.
"cacheability" has misled at least two people (that I can recall) into
thinking that we maintain some kind of function result cache --- which
is not true, and if it were true we'd need the term "cacheable" for
control paramet
Hi,
It's a stupid thing ... but really useful ...
When we use, like me, psql all the time with the function VACUUM, psql
make the completion of tables names, and of the word ANALYZE ...
Why not the same for VERBOSE ? and for the new function FULL, and FREEZE
??
May be in the TODO for next rele
Jan Wieck <[EMAIL PROTECTED]> writes:
> ... And PostgreSQL needs some frequent VACUUM
> anyway, so after a while this problem solves itself for the
> average user.
Yes, that's the key point for me too. Anyone who doesn't set up for
routine vacuums/analyzes is going to have per
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I was thinking about handling this
> within initdb, with a display like this:
> """
> The files belonging to this database system will be owned by user "peter".
> This user must also own the server process.
> Locale settings: collate=en_US ctype=en_
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> It could also be considered deterministic, strict, cacheable,
> mathematically sensible, real, pleasant, or good. ;-)
> Out of those, I believe "const" is the worst term, because saying "sin(x)
> is a constant function" sounds pretty wrong.
Yeah, th
mlw writes:
> For each page hit, I do this:
>
> update pagecounts set counter = counter + 1 where pagename = 'testpag.php'
>
> Do I have to set a particular isolation level? Or does this not work in
> general?
In read committed level, if the second update launches before the first
update is fini
Martin Renters <[EMAIL PROTECTED]> writes:
> It is also pretty unreasonable to think that any company is
> going to switch providers because of one blacklist or somehow complain
> to their ISP about the spammers the ISP is hosting without any more
> detail than:
> "Blacklist X says you prov
Tom Lane writes:
> It might be that Bruce's recent changes to elog levels allow a graceful
> compromise about backend messages during initdb. I haven't looked, but
> maybe initdb could run the backend with message level one notch higher
> than LOG to suppress all the normal-case messages without
Peter Eisentraut wrote:
>
> Tom Lane writes:
>
> > mlw <[EMAIL PROTECTED]> writes:
> > > (1) const or constant
> > > (2) cacheable
> > > (3) volatile
> >
> > I was wondering about "const" for case 1, also. I think there is some
> > precedent for using "const" with this meaning in other programm
Peter Eisentraut wrote:
>
> mlw writes:
>
> > update mytable set foo=foo+1 where bar='xxx';
> >
> > If that gets executed more than once at the same time by multiple instances of
> > postgresql. Will foo ever lose a count?
>
> No, but if you run this in read committed isolation mode then you mi
Hi Jan,
Jan Wieck wrote:
>
> The defaults after a restore should result in index scans
> most of the time, resulting in some medium decent
> performance. And PostgreSQL needs some frequent VACUUM
> anyway, so after a while this problem solves itself for
mlw writes:
> A function, such as sin(x) could be considered constant for the result based on
> value 'x'
It could also be considered deterministic, strict, cacheable,
mathematically sensible, real, pleasant, or good. ;-)
Out of those, I believe "const" is the worst term, because saying "sin(x)
mlw <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Sorry about that. I like 510sg's dnsbl list precisely because it's
>> aggressive, but sometimes it's too aggressive. I can whitelist you
>> if you have a stable IP address ... is 24.147.138.78 a permanently
>> assigned address, or not?
> I wi
mlw writes:
> update mytable set foo=foo+1 where bar='xxx';
>
> If that gets executed more than once at the same time by multiple instances of
> postgresql. Will foo ever lose a count?
No, but if you run this in read committed isolation mode then you might
get into non-repeatable read type probl
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> That said, I'd like to block some spam myself. I'd rather find a spam
> list which doesn't already have me disallowed however...
In case it makes you feel better: my *own* address was on the 510sg list
for awhile last month. But I still use the list
Peter Eisentraut wrote:
>
> Tom Lane writes:
>
> > mlw <[EMAIL PROTECTED]> writes:
> > > (1) const or constant
> > > (2) cacheable
> > > (3) volatile
> >
> > I was wondering about "const" for case 1, also. I think there is some
> > precedent for using "const" with this meaning in other programm
Tom Lane writes:
> mlw <[EMAIL PROTECTED]> writes:
> > (1) const or constant
> > (2) cacheable
> > (3) volatile
>
> I was wondering about "const" for case 1, also. I think there is some
> precedent for using "const" with this meaning in other programming
> languages.
I think the meaning of "con
Justin Clift wrote:
> Tom Lane wrote:
> >
> > Gavin Sherry <[EMAIL PROTECTED]> writes:
> > > On Wed, 3 Apr 2002, Christopher Kings-Lynne wrote:
> > >> Would it be an idea to have pg_dump append an ANALYZE; command to the end of
> > >> its dumps to assist newbies / inexperienced admins?
> >
> > > I
...
> I'm not sure I'm the only one, am I?
No, I was also blocked from Tom's mail a while ago. I have a static IP,
but my ISP's entire block of addresses made it on to the spam list Tom
uses, and the strategy of the list maintainers seems to be to maximize
the collateral damage to force me to som
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Wed, Apr 03, 2002 at 10:23:41AM -0500, Tom Lane wrote:
>> But I can't see any reasonable way for configure to decide automatically
>> whether we should replace the system qsort. I think we'd have to put
>> a USE_PRIVATE_QSORT symbol definition into
Doug McNaught wrote:
> I think most vendors do a pretty good job. Don't forget, optimizing a
> routine like that depends a lot on the cache size and behavior of the
> CPU and other architecture-dependent stuff.
>> qsort() is a great sort for very random data, when data is mostly in the
>> corr
Doug McNaught <[EMAIL PROTECTED]> writes:
> Actually, the C standard says nothing about what algorithm should be
> used for qsort(); it's simply supposed to be a fast in-memory sort.
> The qsort() name is just a historical artifact.
In practice I believe qsort usually is a quicksort; it's just to
Tom Lane writes:
> > initdb --lc-collate, initdb --locale, LC_ALL, LC_COLLATE, LANG
> > initdb --no-locale is the same as initdb --locale=C, for convenience.
>
> I'm confused; what is the default behavior if you don't give any
> switches to initdb?
Whatever is set in the environment -- which boi
Christopher Kings-Lynne writes:
> usa=# \i ~/ddlpack/kl_setnotnull.sql <-- tab completes properly
> ~/ddlpack/kl_setnotnull.sql: No such file or directory
The tilde is only meaningful in bash (or some other shell).
Try putting this in your .inputrc:
$if psql
set expand-tilde on
$endif
That
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > Tom: My mail doesn't reach you. As an AT&T user, you block my machine's IP
> > address with the anti-spam blocking. :-(
>
> Sorry about that. I like 510sg's dnsbl list precisely because it's
> aggressive, but sometimes it's too aggressive.
mlw <[EMAIL PROTECTED]> writes:
> > Because qsort() is *supposed* to be optimized by the vendor for their
> > platform, perhaps even written in assembler. It makes sense to trust
> > the vendor except when their implementation is provably pessimized.
>
> Perhaps *supposed* to be optimized, but,
mlw <[EMAIL PROTECTED]> writes:
> (1) const or constant
> (2) cacheable
> (3) volatile
I was wondering about "const" for case 1, also. I think there is some
precedent for using "const" with this meaning in other programming
languages. "volatile" for case 3 seems reasonable.
> Tom: My mail does
Doug McNaught wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
>
> > I noticed poor performance on Solaris, does one see this problem
> > when compiling PostgreSQL with gcc on solaris?
>
> Since it's libc that's the culprit, I would imagine so.
Thanks, that explains what I have seen.
>
> > As a sug
John Gray <[EMAIL PROTECTED]> writes:
> Here's my current working draft (doesn't include material from the
> last couple of weeks):
Please note that there's been pretty substantial revisions in command.c
and creatinh.c over the past couple of weeks for schema support. While
I think that those tw
mlw <[EMAIL PROTECTED]> writes:
> I noticed poor performance on Solaris, does one see this problem
> when compiling PostgreSQL with gcc on solaris?
Since it's libc that's the culprit, I would imagine so.
> As a suggestion, why not find the *best* version of qsort available,
> anywhere, and alwa
On Wed, Apr 03, 2002 at 10:23:41AM -0500, Tom Lane wrote:
> Justin Clift <[EMAIL PROTECTED]> writes:
> > How about we include this and have configure somehow ensure the Solaris
> > users get it automatically?
>
> Hmm. I suppose there'd be no license issues with borrowing a BSD qsort.
> But I ca
Gavin Sherry <[EMAIL PROTECTED]> writes:
>> Because there is no other easy way to guarantee message delivery?
> Shared memory is much easier and, to all intents and purposes, as reliable
> for this kind of usage. It is much faster and is the-right-way-to-do-it.
Right. Since we do not attempt t
Tom Lane wrote:
>
> Justin Clift <[EMAIL PROTECTED]> writes:
> > Mark kirkwood wrote:
> >> Indeed it is - obtained qsort.c from Freebsd CVS and rebuilt Postgresql :
> >> The query now takes 6 seconds instead of 1 hour ! Thanks for an
> >> excellent suggestion.
>
> > How about we include this and
On Tue, 2 Apr 2002, Barry Lind wrote:
> Since both the JDBC and ODBC specs have essentially the same symantics
> for this, I would hope this is done in the backend instead of both
> interfaces.
The current plan seems to be to make changes in the backend and the JDBC
interface, the bulk of the
Daniel Kalchev <[EMAIL PROTECTED]> writes:
> There is more to it:
> customer=# select max(oid) from croute;
> max
> -
> -2144025472
> (1 row)
> How to handle this?
Use a more recent Postgres release. max(oid) behaves as expected in
7.2. Before that it was piggybacking o
Justin Clift <[EMAIL PROTECTED]> writes:
> Mark kirkwood wrote:
>> Indeed it is - obtained qsort.c from Freebsd CVS and rebuilt Postgresql :
>> The query now takes 6 seconds instead of 1 hour ! Thanks for an
>> excellent suggestion.
> How about we include this and have configure somehow ensure th
On Wed, 3 Apr 2002, Mikhail Terekhov wrote:
>
>
> Tom Lane wrote:
>
>
> > There is a very significant performance problem with LISTEN/NOTIFY
> > via pg_listener: in any application that generates notifications at
> > a significant rate, pg_listener will accumulate dead tuples at that
> > sam
I am full agreement with proposal. I love it!!
(1) const or constant
(2) cacheable
(3) volatile
P.S.
Tom: My mail doesn't reach you. As an AT&T user, you block my machine's IP
address with the anti-spam blocking. :-(
---(end of broadcast)---
TIP
Take this update statement:
update mytable set foo=foo+1 where bar='xxx';
If that gets executed more than once at the same time by multiple instances of
postgresql. Will foo ever lose a count?
I am assumed that foo will always be correct and that the database will manage
any contention, but w
Tom Lane wrote:
> There is a very significant performance problem with LISTEN/NOTIFY
> via pg_listener: in any application that generates notifications at
> a significant rate, pg_listener will accumulate dead tuples at that
> same rate, and we will soon find ourselves wasting lots of time
>
Just curious - why is solaris qsort that way? Any good reasons? I saw a
very old post by a solaris guy, but it didn't seem very convincing.
By the way are there faster sorts which Postgresql can use for its sorting
other than quick sort? e.g. BSD 4.4 radixsort (which DJB seems to keep
going on
On Wed, 2002-04-03 at 09:39, Christopher Kings-Lynne wrote:
> Hi All,
>
> With regards to the proposed command.c refactoring...
>
..about which I should apologise as I stuck my head above the parapet
and then sat on my ideas (mixing metaphors a bit).
> I've done it by removing command.c and rep
Hi All,
With regards to the proposed command.c refactoring...
I've done it by removing command.c and replacing it with
portal.c
alter.c
lock.c
namespace.c
Is that a good idea? Will it break too many outstanding patches?
Basically the portal fetch/destroy commands go in portal.c, all the Alte
Tom Lane wrote:
>
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > On Wed, 3 Apr 2002, Christopher Kings-Lynne wrote:
> >> Would it be an idea to have pg_dump append an ANALYZE; command to the end of
> >> its dumps to assist newbies / inexperienced admins?
>
> > I do not think this is desired beha
89 matches
Mail list logo
