I did some experimentation just now, and could not get mysql to accept a
command longer than about 1 million bytes. It complains about
Got a packet bigger than 'max_allowed_packet' bytes
which seems a bit odd because max_allowed_packet is allegedly set to
16 million, but anyway I don't think p
I did some experimentation just now, and could not get mysql to accept a
command longer than about 1 million bytes. It complains about
Got a packet bigger than 'max_allowed_packet' bytes
which seems a bit odd because max_allowed_packet is allegedly set to
16 million, but anyway I don't think p
The major downside is that somewhere between 9000 and 1
VALUES-targetlists produces "ERROR: stack depth limit exceeded".
Perhaps for the typical use-case this is sufficient though.
I'm open to better ideas, comments, objections...
If the use case is people running MySQL dumps, then there
Hang on a second. Has someone considered the encoding issues this might
suffer from, same as PQescapeString? I remember we discussed it briefly
and I mentioned it's outta my league to prove one way or the other...
Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
TODO item done fo
I thought of that but I assume we were not accepting user-supplied
identifiers for this --- that this was only for application use. Am I
wrong?
Well, yes the plan was to accept user-supplied identifiers...
If you insist on a practical example, I can certainly imagine someone
thinking it'd be
For instance, I'd like to 'enable slony support' if the slony shared
library is present. PPA's slony support automatically executes the .sql
files, so all I need to know is if the .so is there.
I really think this is backwards: you should be looking for the .sql
files. Every module will have
Marko's suggestion on producing a list of installed modules comes to mind, and
I suspect tools like pgadmin or ppa will want to be able to show this
information.
My request for phpPgAdmin is to somehow be able to check if the .so file
for a module is present.
For instance, I'd like to 'enabl
from all libpq-using applications not just psql. We could make this
conditional on the error verbosity --- in "terse" mode the "LINE N"
output wouldn't appear, and "at character N" still would. Applications
should already be expecting multiline outputs from PQerrorMessage if
they're in non-terse
The point here is that if tuples require 50 bytes, and there are 20
bytes free on a page, pgstattuple counts 20 free bytes while FSM
ignores the page. Recording that space in the FSM will not improve
matters, it'll just risk pushing out FSM records for pages that do
have useful amounts of free sp
Bruce Momjian wrote:
I have remove the LEFT part of the join to pg_roles in
psql/description.c. I assume this is too risky for 8.1.X.
Well, 8.1 already has per-role dependencies, so why not do it?
I agree
---(end of broadcast)---
TIP 4: Have
Here's a first draft patch for DROP ... IF EXISTS for the remaining
cases, namely: LANGUAGE, TABLESPACE, TRIGGER OPERATOR CLASS,
FUNCTION, AGGREGATE, OPERATOR, CAST and RULE.
At what point does this stop being useful and become mere bloat?
The only case I can ever recall being actually asked
I think it is worth distinguishing more clearly between portals that
should be displayed to the user and those that should not (which might
be labelled "internal cursors", perhaps). The tests above seem fairly
ad-hoc.
With all this system view love going on, is there any point having a
'pg_save
Agreed. I have gotten confused on how to set $user in the past. I have
developed the following patch that sets the default with the double
quotes around it, and it works fine. The patch also contains updated
documentation.
Just be careful about pg_dump's special handling of search_path in use
Pavel Stehule wrote:
x, y := r;
That strikes me as a really bad idea. It weakens both syntax and
semantic error checking, to accomplish how much?
Could use PHP-style thingy:
LIST(x, y) := r;
Chris
It's inconsystency :-(.
EXECUTE INTO and SELECT INTO use scalar of vectors without
x, y := r;
That strikes me as a really bad idea. It weakens both syntax and
semantic error checking, to accomplish how much?
Could use PHP-style thingy:
LIST(x, y) := r;
Chris
---(end of broadcast)---
TIP 9: In versions below 8.0, the pla
Short of going to a wiki, I think we can at least make it easier for
other committers to modify the TODO list. What format is doc/TODO in,
anyway? (It doesn't seem to be normal plaintext.) Why is there also an
HTML copy of the TODO list (doc/src/FAQ/TODO.html) kept in CVS? (I'd
rather we not keep
BTW, has anyone checked Command Prompt's Subversion repository? It's a
mirror of our anonymous CVS (AFAICT). I'm using it for reading diffs
lately, and it's much nicer to look at the whole patch as a single diff
rather than going a single file at a time.
http://projects.commandprompt.com/projec
This fixes pg_dump so that when using the '-O' no owners option it does
not print the owner name in the object comment.
Why is that a good idea?
At the moment I want to dump sample databases for a project. I don't
want my name or username appearing anywhere in them. I dump without
owners o
This fixes pg_dump so that when using the '-O' no owners option it does
not print the owner name in the object comment.
eg:
--
-- Name: actor; Type: TABLE; Schema: public; Owner: chriskl; Tablespace:
--
Becomes:
--
-- Name: actor; Type: TABLE; Schema: public; Owner: -; Tablespace:
--
This ma
If the consensus is to add this to all of them, then I propose to apply
the patch I have (with a slight fix for an oversight in the case of
domains, plus docs and tests) for the 8 cases and start working on the
remaining 13 as time permits. To be honest, I have not even looked at
those 13 cases
Including objects that already have CREATE OR REPLACE?
I assume so - CREATE OR REPLACE doesn't drop things - only creates or
replaces them.
Chris
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
I think anything else will have to be done individually, although the
pattern can be copied.
Perhaps we should take bids on what should/should not be covered.
Everything should be covered, otherwise it's just annoying for users...
Chris
---(end of broadcast)--
Will we get this functionality for ALL objects?
Bruce Momjian wrote:
Removed from queue. Andrew is committing it.
---
Andrew Dunstan wrote:
OK, now it looks like this:
andrew=# drop table blurflx;
ERROR: table "blurfl
Want to host it on pgfoundry until 8.2 is released?
Mark Kirkwood wrote:
This patch implements a view to display the free space map contents - e.g :
regression=# SELECT c.relname, m.relblocknumber, m.blockfreebytes
FROM pg_freespacemap m INNER JOIN pg_class c
That was probably done deliberately, back in the day when constraints
tended to have uselessly random names like "$1" --- sorting by the
constraint text was more helpful. I agree that now sorting by name
seems like the better thing.
Even in the "$x" case, it's better to have them sorted in that
Everything is sorted by object name in \d except check
constraints for some reason. It seems it's ordering by the wrong column.
Seems like a bug to me.
Attached is the trivial patch.
Chris
Index: src/bin/psql/describe.c
===
RCS
So what? I just don't see consistency as being a value in itself, but
only when it has some other merit. Clearly you don't agree, but I am
with Emerson on the subject of consistency.
So you're saying you're consistent in your objections to consistency? :)
---(end of br
We have to consider what
happens at stat reset -- AFAICS there's no problem, because as soon as
the table sees some activity, it will be picked up by pgstat.
However, it would be bad if stats are reset right after some heavy
activity on a table. Maybe the only thing we need is documentation.
You are into the cycle we were in. We discussed pg_object size (too
vague) and pg_index_size (needs pg_toast_size too, and maybe toast
indexes; too many functions).
Yeah, I read those discussions, and think you were better off then than you
are now, which is why I went back to it somewhat.
Satoshi Nagayasu wrote:
>>The table owner can drop and create triggers - so why shouldn't they be
>>able to enable and disable them?
>
>
> For convenience or easy operation.
>
> I believe the user doesn't like to create same triggers again and again.
I said why _shouldn't_. I was agreeing wi
>>ALTER TABLE ENABLE TRIGGER
>>ALTER TABLE DISABLE TRIGGER
>
>
> Bruce said to allow them only super-user,
> but currently this patch allows also the table owner.
The table owner can drop and create triggers - so why shouldn't they be
able to enable and disable them?
Chris
---
The trick in hacking pg_dump is to understand which layer you need to
modify. The whole thing seems overly complex to me :-( ... but
redesigning it is a project for another release cycle.
I just find the whole BLOB handling very tricky to understand :(
I vote that we combine pg_dumpall and pg_
Attached patch enables dumping of LOB comments when in text mode.
I really don't get the binary/custom format LOB stuff (and don't have
time to investigate), so perhaps someone else can do that.
That's pretty icky :-(. I think the right way is more like this.
Hehe - in the world of open sou
Hi,
Attached patch enables dumping of LOB comments when in text mode.
I really don't get the binary/custom format LOB stuff (and don't have
time to investigate), so perhaps someone else can do that.
Having it in text format is still an improvement though.
Chris
blobcomments.txt.gz
Descript
* Allow backslash handling in quoted strings to be disabled for
portability
The use of C-style backslashes (.e.g. \n, \r) in quoted strings is not
SQL-spec compliant, so allow such handling to be disabled. However,
disabling backslashes cou
Yep, you probably are. The hurt is backward compatibility, but the gain
is greater portability with other database systems.
It's just going to break millions of PHP scripts :(
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe comm
I'm still really iffy about this. I think it will really hurt pgsql due
to backward compatibility :(
(If I'm understanding how the proposed change works...)
Chris
Bruce Momjian wrote:
A summary of my proposal to add a new E'' string for escape and have
non-E escapes not handle backslashes s
pokus=# create or replace function x() returns void as $$
declare c integer[] = '{10,20,30}'; a integer = 3;b record;
begin b := row(1,2);
raise notice 'sss % % % % % % % % %', interval '23 hour',
1, current_user, c,now(), c[1],
(select * from fx where 1 = 0 limit 1),
null,curre
I don't see anyone very excited about r-tree these days; have you
noticed that no one has stepped up to repair the known semantic errors?
I wouldn't spend any time on it in the prover.
That sort of thing is always self-fulfilling. If rtrees were fast,
logged and rad, then more people would use
lastval() returns the last value produced by nextval() or setval() in
the current session.
I'm in favour of that definition...
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregiste
Anyway, let me take a look at it in a minute. My main comment is that it's
not the code that's the main thing to fix but to decide is if we want the
feature at all.
I want the feature. Is useful for PHP ...
Chris
---(end of broadcast)---
TIP 8:
What would be absolutely ideal is a reset connection command, plus some
way of knowing via the protocol if it's needed or not.
Chris
Bruce Momjian wrote:
What did we decide on RESET CONNECTION. Do we want an SQL command or
something only the protocol can do?
-
I expect so less used functions will go to contrib: LNNVL, .. but some
functions can by general usefull. There is WIDTH_BUCKET in core too now.
Who use it?
Width_bucket is in the sql standard...
---(end of broadcast)---
TIP 1: subscribe and uns
The implementation in this patch has the same problems as all the
previously rejected attempts: it evaluates its arguments twice. You
need to make BETWEEN SYMMETRIC into a separate node type that evaluates
each argument only once.
And that's also been submitted. The problem then is making th
I like the concept, but I haven't looked at the code -- I'd be happy to
review the implementation, although I won't waste my time if most people
are opposed to the idea itself.
It'd make implementing various PHP userland functions a real breeze...
Chris
---(end of broadcas
Seems like an idea to me...
On another note, what about the problem I pointed out where it's not
possible to drop the default on a serial column after you alter it to a
varchar, for example...
Chris
On Sat, 7 May 2005, Bruce Momjian wrote:
Christopher Kings-Lynne wrote:
I don't thin
f the PostgreSQL committers reviews
and approves it.
---
Christopher Kings-Lynne wrote:
This patch updates psql and pg_dump to use the new copy api. Probably
needs some review.
I have tested it with dos and unix newlines, etc.
Chris
Co
+0800, Christopher Kings-Lynne wrote:
Luckily, PG 8 is available for this. Do you have a short example?
No, and I think it should be in the manual as an example.
You will need to enter a loop that uses exception handling to detect
unique_violation.
Pursuant to an IRC discussion to which Dennis
Thinking about this - with the new PQputCopyEnd, the sending of \. can
probably also be removed.
Chris
Christopher Kings-Lynne wrote:
This patch updates psql and pg_dump to use the new copy api. Probably
needs some review.
I have tested it with dos and unix newlines, etc
I implemented the user-visible side of this (FKs in particular) using a
new "FOR SHARE" clause to SELECT. This is of course open to
suggestions. Inside the grammar I hacked it using the productions for
FOR UPDATE, and stashed a String as the first node of the relid List.
Well MySQL uses "IN SHARE
The attached patch allows EXPLAIN ANALYZE to break out the time spent in
triggers when EXPLAINing a statement that can fire triggers. Formerly
this time was included in "Total runtime" but not otherwise accounted
for.
Actually, should you make it talk about RULEs as well?
Chris
---
Right. So what's the point? It seems like the printout would just be
useless noise: it'd repeat N times the estimate of the top-level number
of output rows.
Well I guess the point would be to remind people that there are
(potentially) expensive triggers that will run, so even though the
analysi
Could we get plain EXPLAIN output as well:
Plain EXPLAIN doesn't run the query, and therefore not the triggers.
But the point of it is to estimate, right? Could it not estimate the
number of time each trigger would be called. Surely that's the same as
estimating the number of rows each clause w
The attached patch allows EXPLAIN ANALYZE to break out the time spent in
triggers when EXPLAINing a statement that can fire triggers. Formerly
this time was included in "Total runtime" but not otherwise accounted
for.
Very nice.
An example is
regression=# explain analyze delete from foo;
This patch updates psql and pg_dump to use the new copy api. Probably
needs some review.
I have tested it with dos and unix newlines, etc.
Chris
? src/bin/initdb/.deps
? src/bin/initdb/initdb
? src/bin/ipcclean/ipcclean
? src/bin/pg_config/.deps
? src/bin/pg_config/pg_config
? src/bin/pg_control
This just adds a link to the pattern_ops operator class section from the
part of the locale docs that mentions that indexes don't work for LIKE
under a non-C locale.
(untested)
Chris
Index: doc/src/sgml/charset.sgml
===
RCS file: /p
This patch makes \d on tables and views sort fk constraints, triggers
and rules alphabetically in the output. This makes it the same as for
indexes and stops the irritating random or reverse ordering it currently
has.
Chris
Index: src/bin/psql/describe.c
===
I find this tiny (9-line) patch useful to help my clients know
when FSM settings may need updating.
Some of the more frequently asked questions here are in regards to FSM
settings. One hint I've seen is to run "vacuum verbose;". At the end
of thousands of lines of INFO and DETAIL messages
Uh, how is it more expressive? The only difference I see is the
line numbers. Is that it?
That could be a very big deal in case of error on a large file, so
yes.
In IRC, I always recommend that ppl use -f, since it's so much more
useful :)
Chris
---(end of broadcast)---
This one from Ben Calvert. It uses the (imho clearer) NOW() rather
than 'NOW' in a PL/PgSQL function example.
Applied, thanks.
Why not use CURRENT_TIMSTAMP instead of NOW() everywhere in the docs. I
mean, it's standard and NOW() isn't...
Chris
---(end of broadcast)-
I've attached a revised patch which fixes the problem, however I'm sure there
is a better way. Thanks to Neil for putting up with me on irc :-)
How about calling the savepoint pg_psql_savepoint instead, that way it
follows our 'don't begin things with pg_' philosophy.
Chris
The usefulness of this seems pretty dubious. You aren't going to have a
bunch of random bits of code sharing a connection; it's going to be a
single application that probably knows perfectly well exactly which
queries it needs prepared. So I don't think the stats will pay for
themselves.
Not true
I don't see this as all that helpful for a client interface that does the
preparation itself. Possibly it could be used for libpq, but you
mentioned DBI which should already know what it has or has not prepared.
The idea of adding a network round trip to detect a prepared statement
seems like a
Please ignore- seems some old mail of mine got sent waaay late...
Christopher Kings-Lynne wrote:
I am not fond of the timeline idea, especially for 7.5. Let's get usage
cases submitted first. I can imagine timelines as causing significant
confusion during restore, which is the last thing we
I am not fond of the timeline idea, especially for 7.5. Let's get usage
cases submitted first. I can imagine timelines as causing significant
confusion during restore, which is the last thing we want to do.
I think that judgment is exactly backward. *Not* having timelines is
what will cause seri
This adds mention of my latest tweak to the tsearch2/pg_trgm
integration. It is much better to create a word list of unstemmed words
than stemmed ones.
Chris
Index: contrib/pg_trgm/README.pg_trgm
===
RCS file: /projects/cvsroot/pgs
Um ... what's an htmlhelp?
It's the kind of format the Windows'ish programs use for their internal help
browsers. It consists of regular HTML plus some index files. pgAdmin needs
it, and maybe the Windows binary package would like it as well.
I've trivially generated them from docbook xml using
May as well downgrade the CLOG message as well then.
Chris
Greg Sabino Mullane wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
On August 9, Tom Lane wrote regarding "recycled transaction log file"
messages appearing in the server logs:
At least we are guaranteed to compile against current libraries - apps
outside the source tree never get that luxury and have worse
compatibility problems. :)
The issue is that no one has been asking for this functionality, and I
can imagine it becoming quite a mess after a few releases.
No messier
If I get time, I will begin making psql backward-compatible to 7.3 and
further, but the changes to do so will not be as small as this patch
and I would rather they get evaluated separately.
But do we want to do this? Is it worth doing, and maintaining?
Yes please, I'll maintain it as well :)
Chris
One of the things I still intend to do is make psql work against all
previous backends, so this patch is a good first step :)
For example, we have web servers on database servers on different
machines. Recompiling psql on the web servers is a PITA since it means
recompiling PHP then recompilin
I wonder...
Maybe you don't need to override to_timestamp, and you can just add a
new code to the format string that to_timestamp understands, ie 'e' or
something or 'u' that means 'unix timestamp'?
Chris
Michael Glaesemann wrote:
Please find attached a patch (diff -c against cvs HEAD) to add a
$ pg_dump regression >zzz.out
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR: "complex" is a composite type
pg_dump: The command was: COPY public.complex (r, i) TO stdout;
$
That could be fixed by just checking the relkind when dumping table
data, but hey.
I suspect it had
Now it's entirely possible that the underlying support is a few bricks
shy of a load --- for instance I see that pg_utf_mblen thinks there are
no UTF8 codes longer than 3 bytes whereas your code goes to 4. I'm not
an expert on this stuff, so I don't know what the UTF8 spec actually
says. But I do
OK, it looks good. I don't have latex handy to build it, but it looks
fine to me...
Chris
Bruce Momjian wrote:
If you would like to review it I will apply it.
---
Christopher Kings-Lynne wrote:
Surely this is a really
Applied. I notice though that the line numbers don't seem to match CVS
tip, which suggests that you've got some patches still unapplied? If
so, Bruce seems to have missed adding them to the patch queue.
Hmmm, no... Not sure what happened there. The diff in the committers
email seemed fine howe
OK, when I find a moment.
Bruce Momjian wrote:
If you would like to review it I will apply it.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Surely this is a really good bug fix and should be in 7.5?
Bruce Momjian wrote:
This has been saved for the 7.6 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---
Roger Leigh wrote:
I have noticed that the lat
You mean 8.1 release :P
Bruce Momjian wrote:
This has been saved for the 7.6 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister
Applied. I also added some code to ruleutils.c to make
pg_get_constraintdef output the USING INDEX TABLESPACE clause at need.
We might want to think about getting pg_dump to rely more on
pg_get_constraintdef and friends, instead of native wit ...
Yes, that was really dumb of me not to think of tha
* You had consistently changed the simple_heap_update calls to do the
wrong thing. (I'm surprised it didn't blow up on you in your testing.)
In a sequence like
newtuple = heap_modifytuple(tup, rel, repl_val, repl_null, repl_repl);
simple_heap_update(rel, &newtuple->t_self, newtuple
I'm also wondering about what side-effects this will have on pg_dump
behavior. In particular, will pg_dump try to "ALTER OWNER public",
and if so will that be appropriate? We haven't previously needed to
assume that we are restoring into a database with the same datowner as
we dumped from...
In m
Attached is a patch that fixes the owner change command on objects that
have privileges.
It probably needs a once over review since it involves a decent amount
of pointer arithmetic.
Note that languages don't have owners, and hence don't need fixing.
The owner change acl support is as follows:
create table test (a integer primary key index tablespace loc);
create table test (a integer unique index tablespace loc);
create table test (a integer);
alter table test add primary key(a) index tablespace loc;
create table test (a integer);
alter table test add unique(a) index tablespace loc;
Cra
The attached patch allows the specification of the tablespace the index
is to be created in for unique and pk constraints. It also fixes the
dumping of such constraints so that they are restored into the correct
tablespace, after they have been moved with SET TABLESPACE. This is
currently an
This patch does two things to pg_dump:
* Dumps comments on columns of composite types
* Instead of putting all the OWNER TO commands at the end, it dumps then
after each object. This is WAY more readable and nice. ACLs are still
at the end.
Chris
pg_dump5.txt.gz
Description: GNU Zip compress
If you want to put in the function and document that it may cause
problems, I won't object; it's not like we don't have other features
that are poorly implemented :-(. But my vote would be to remove it.
I'm down with removing it - people don't read documentation :/
Chris
--
The first time I used it was for precisely this reason - some buggy PHP code opened
hundreds of connections to a dev server which then remained open doing nothing except
wasting resources. It was particularly useful in that case as I didn't have access to
the web server at the time.
Shortly afte
Would you use a kill operation in the way you describe above if you knew
that it had, say, a 1% chance of causing a database-wide PANIC each time
you used it?
The odds of a problem are probably a great deal less than 1%, especially
if the backend is sitting idle. But they're not nil, and I don't t
I'm in favour of how it is now, so long as the comment is clear. It's
the Unix Way :)
Chris
I'd vote for it as a clarity factor too.
Klaus Naumann wrote:
On Tue, 20 Jul 2004 [EMAIL PROTECTED] wrote:
FATAL: unrecognized configuration parameter "archive_mode"
Have I missed something since it h
The last patch of mine you committed just made it all DROP TABLE
public.tab; That at least makes it work.
Chris
Bruce Momjian wrote:
Where are we on this?
---
Kris Jurka wrote:
When running pg_dump --clean against a server t
No, it doesn't. I can look into that if you like. The patch was
entirely to satisfy a need some of our customers have. The -T switch
does fill a real need for our customers; our product has a couple of tables
that aren't critical if they aren't backed up, but as the product evolves,
we occasiona
Yes, the reason it would be nice for me is that currently if you want to
dump two specific, related tables from your db, there's no way to do it
with pg_dump within the one transactions (ie. maintaining integrity). I
guess I'm in favour of -t -t but not -T depending on the complexity of
it. I
Well, I guess I'm against it based on the rules of feature freeze,
even though it would be really useful for me :(
It would have been a lot easier to approve it if it'd arrived on June 30
rather than July 6 :-(. However, I do believe that David originally
submitted a slightly-too-late version
I see one vote in favor of its inclusion on the grounds it is a bug not
to support multiple -t parameters. However, is someone objects I will
have to hold it for 7.6. It needs SGML doc additions which I will do
myself.
Well, I guess I'm against it based on the rules of feature freeze,
even t
Okay, we agree on that part at least; I'll take care of it. If anyone
wants to argue for further copying during initdb, that can be added
later.
I reckon it should be copied into $PGDATA :) Otherwise, when I'm in a
panic at recovery time, I'd have to figure out where the heck my package
has ins
Can we please have it default to enabled :)
We can but without also enabling statistics it will not work. Do we
want to enable both by default?
Weeell...it just seemed to me that we won't cut down on the support
mails unless it's on by default... I mean at some point in the future,
we WILL hav
The thing I was trying to do was use the GUC hook function to make
sure that the required GUC variables are also set before GUC reports
autovac as enabled. This seemed cleaner to me, but apparently it
won't work since it seems that autovac_enabled is read from GUC
before the stats variables, and t
OK,
Here is another patch that fixes a stack of pg_dump bugs:
* Fix help text ordering
* Add back --set-session-authorization to pg_dumpall. Updated the docs
for that. Updated help for that.
* Dump ALTER USER commands for the cluster owner ("pgsql"). These are
dumped AFTER the create user and
Hehe - actually, don't commit this either, I keep finding more and more
bugs in pg_dump...
Chris
Christopher Kings-Lynne wrote:
OK,
This dump is a proper fix for the three bugs mentioned in the first email.
It now just outputs an ALTER USER command for the cluster owner and has
nothing
1 - 100 of 214 matches
Mail list logo
