OK; the only change in this version is isconst = false;. Now you can
use $0 as a result placeholder if desired. E.g.:
Can we get any inspiration from Perl or bash here? eg. $$ or $* or
whatever?
Chris
---(end of broadcast)---
TIP 4: Don't
Do we need a 'AND NOT a.attisdropped' in there anywhere as well?
Chris
On Tue, 23 Sep 2003, Irina Sourikova wrote:
Hi,
I tried to use vacuumlo of posgres-7.3.4/contrib/vacuumlo and it didn't
work
for me until I added one line:
strcat(buf, AND c.relname 'vacuum_l');
after
Hi,
The brackets aren't put on the CHECK constraints properly.
Before patch:
test=# select pg_get_constraintdef(oid) from pg_constraint;
pg_get_constraintdef
-
Hi,
This patch finishes off the work that I did with making view
definitions use pretty printing.
It does:
* Pretty check constraints
* Pretty index predicates
* Pretty rule definitions
* Uppercases PRIMARY KEY and UNIQUE to be consistent with CHECK and
FOREIGN KEY
* View rules are improved to
The problem with two lines is that another log message could get between
them. I agree milliseconds makes more sense for output.
That's not a huge problem. I've run our servers like that for ages, and
there's not really any time when a human can't tell what's going on.
You can also turn on PID
It looks like the patch changes translated strings which isn't supposed to
happen. It can of course still be accepted, that's not my call.
Yes, actually it does now that I look at it. However, I submitted this
patch weeks ago. If it's not accepted for the time being due to freeze,
then that's
Save this for 7.5. Nails a TODO item.
Chris
? GNUmakefile
? config.log
? config.status
? src/Makefile.global
? src/backend/postgres
? src/backend/access/common/.deps
? src/backend/access/gist/.deps
? src/backend/access/hash/.deps
? src/backend/access/heap/.deps
? src/backend/access/index/.deps
Won't that result in *everything* being considered a system table?
Doh. Quite right. Well, the 7.0 initdb creates pg_indexes as the last
thing it does. (Even though there are higher oids in pg_attribute,
pg_rewrite and pg_description.), so how about the attached patch?
Chris
Index:
Is this supposed to be applied to CVS?
Well, yes. Assuming Tom doesn't have any problem with it. It's a bug
in dumping 7.0 databases, which should be fixed so that people can
upgrade to 7.4 with less stress :)
Chris
---(end of broadcast)---
Doh - this should have been sent to -patches in the first place...
Chris
Original Message
Subject: Re: [HACKERS] obj_description problems?
Date: Tue, 21 Oct 2003 13:42:16 +0800
From: Christopher Kings-Lynne [EMAIL PROTECTED]
To: Christopher Kings-Lynne [EMAIL PROTECTED]
CC
*sigh* - it's really not my day today. Attached is patch that actually
compiles and fixes the problem. We will need to bump CATVERSION, and
maybe should test all the other qualified functions?
I think you've identified a real issue, but how many of these modified
functions did you actually
Reviewed, tested, applied.
Thanks.
maybe should test all the other qualified functions?
What other qualified functions? There might possibly be some issues in
contrib stuff, but there are no other SQL-language functions defined in
the main system (except information_schema, which we already
Fix two bugs in funcs.source that made the tutorial script fail.
Make a LOT of fixes to syscat.source to:
* Set search_path properly (and reset it)
* Add schema name to all results
* Add schema name to ORDER BY first
* Make checks for user-defined objects match reality
* format_type all type
I notice that the current GiST docs are pretty crazy. Here's my first
attempt at actually making them useful.
(http://developer.postgresql.org/docs/postgres/gist.html)
Interestingly enough, I had a chat with Joe Hellerstein while trying to
write this - he was interested in how GiST was going
I thought I submitted this before, but it seems to have been lost. The
Cygwin docs seemed to be quite out of date. I've updated them. Have a
read to see if you agree.
Chris
Index: FAQ_MSWIN
===
RCS file:
The phrase Cygwin set of DLLs is more accurate. Actually, the phrase
appropriate subset of Cygwin DLLs is even better.
Ok.
! 2. Proceed through the Cygwin install wizard. Choose 'Install from
! Internet', specify a Local Package Directory and choose a mirror
! site that's close to
! 1. Set your path to use the Cygwin bin directory before the Windows
! utilities. Cygwin sort must be used in preference to Windows sort.exe.
Is the above needed during runtime too?
Can anyone see *any* use of sort that would warrant the above step?
I have no idea. I just left that in
! 1. Set your path to use the Cygwin bin directory before the Windows
! utilities. Cygwin sort must be used in preference to Windows sort.exe.
Is the above needed during runtime too?
Can anyone see *any* use of sort that would warrant the above step?
Not in practice. I just dragged it
Here's some improvements. I just ended up referring people to Jason's
website for install as service, because it's a quite a long and complex
process.
Is that README included with the cygwin package, Jason? Because I
couldn't find it in mine...?
Chris
Bruce Momjian wrote:
Jason Tishler
OK, here's a final tweak then.
Chris
Jason Tishler wrote:
Christopher,
On Tue, Nov 11, 2003 at 11:14:44PM -0500, Bruce Momjian wrote:
Patch applied to CVS HEAD and 7.4CVS. Thanks.
Christopher Kings-Lynne wrote:
[snip]
Is that README included with the cygwin package, Jason? Because I
This is expected. Doing otherwise would incur into a much bigger
performance hit.
Anyway, IMHO no code should use SELECT * in any case, which is the only
scenario where one would expect physical column order to matter, isn't
it?
Well, we can always bring back the old idea of a attlognum which is
I guess the real question here is whether we would want to revert this
capability if a patch to adjust logical column orderings doesn't appear
before 7.5. My vote would be no, but apparently Peter's is yes.
Any other opinions?
The fact that it deals with the nightmare of dropping and recreating
This makes help like this:
\lo_export LOBOID FILE
\lo_import FILE [COMMENT]
\lo_list
\lo_unlink LOBOIDlarge object operations
Instead of not saying anything about what arguments are required.
Chris
Index: src/bin/psql/help.c
* You were using a bare C string as the amname argument in COMMENT ON
OPERATOR CLASS. This won't do because the parse tree is not a valid
Node structure; copyObject will fail on it. I inserted makeString()
and strVal() calls to fix it.
BTW, a simple test to detect uncopiable-parsetree problems
Out of interest, I notice you didn't commit my inv_api.c change to
delete comments on LOBs - where did you put it instead?
Doh - just answered my own question - elsewhere in the same file.
Chris
---(end of broadcast)---
TIP 1: subscribe and
Ummm - surely the original was correct?
Chris
Robert Treat wrote:
Marcos Truchado [EMAIL PROTECTED] reported this on -docs yesterday.
Robert Treat
Index: plpgsql.sgml
Hum, sorry to be late, but wasn't one of the supposed strenghts of
pg_dump supposed to be that you could take a dump and load it on a
different RDBMS? I haven't tried it so I don't know if it works, but
this patch takes out the ability to do that -- no one else will accept
WITH/WITHOUT OIDS, so
Did you commit to 7.4.1 too Bruce?
Chris
Bruce Momjian wrote:
Patch applied. Thanks.
---
Jason Tishler wrote:
The attached patch enables contrib/cube to build cleanly under Cygwin
(again). Please consider this patch
Significant effort has been invested to make pg_dump output portable, and
I've not had any problems with it last time I tried it. Please explain
why you think it's totally non-portable.
Functions, indexes, operators, types, aggregates, users, groups,
databases, inheritance, clustering, col
+ SELECT 'epoch'::timestamp + '1070430858 seconds'::interval;
+ lineannotationResult: /lineannotationcomputeroutput2003-12-03
05:54:18/computeroutput
/screen
You could also go:
SELECT '1070430858'::abstime;
But your way is probably a bit more stable...dunno...
Chris
template1=# SELECT '1070430858'::abstime;
ERROR: invalid input syntax for type abstime: 1070430858
I agree its more stable :-). That's on HEAD.
Whoops:
SELECT 1070430858::abstime::timestamp;
Chris
---(end of broadcast)---
TIP 4: Don't 'kill
This patch makes some SGML markup more consistent and makes a small
improvement to the SSL auth docs.
Patch applied to HEAD.
-Neil
You're a committer now, Neil? Way to go! :)
Chris
---(end of broadcast)---
TIP 3: if posting/reading through
initPQExpBuffer(buf);
printfPQExpBuffer(buf,
! SELECT n.nspname AS \%s\,\n
! u.usename AS \%s\\n
FROM pg_catalog.pg_namespace n LEFT JOIN pg_catalog.pg_user u\n
! ON n.nspowner=u.usesysid\n
!
Hey Bruce,
While you're at it - use the same sort of code to conditionally quote
index, rule and constraint names ...
Chris
Bruce Momjian wrote:
psql \d always double-quotes table names:
Table public.xx
Column | Type | Modifiers
Not that this is incorrect. You need to go:
LIKE 'pg_temp_%' probably.
Got it.
Yes. Sigh. It's so annoying living about 15 hours out from when all
this stuff happens :P
I read a thread, come across something, and then make a contribution,
only to read about 40 threads down that the
While you're at it - use the same sort of code to conditionally quote
index, rule and constraint names ...
That makes you part of the problem, because these sections are impossible
to translate correctly.
Now you've lost me - how is a user-inputted object name translatable?
Chris
This is a preliminary patch - don't commit it.
What this patch adds are the CATALOG and NOCATALOG clauses to the CREATE
USER and ALTER USER commands.
These clauses affect the usecatupd column. This makes it easy to create
superusers who cannot manually modify columns (a very nasty power...)
I think you can provide a precise specification without losing
simplicity of explanation. Maybe something like
When step is positive, zero rows are returned if start stop.
Conversely, when step is negative, zero rows are returned if
start stop. It is an error for step to be zero.
Scott Goodwin wrote:
Using schemas is fun. Setting the search_path every time I use psql
isn't. This patch modifies startup.c in psql to allow the SEARCH_PATH to
be set to whatever the PG_SCHEMA_SEARCH_PATH environment variable is set
to. If the var is not defined or is empty, no action is
No, I didn't know that, but I figured there might be another, better way
to do this that I hadn't found. Thanks for the info; I'm going to dig
into ALTER USER to see what else I may be missing. Consider this patch
rescinded, though it was a good exercise in working with PG source
code. If
Thomas Hallgren wrote:
Sure, I'll provide some docs. Just wasn't aware that patchers did that.
- thomas
Yeah, in PostgreSQL, whoever writes the patch also must submit docs.
It's the best way of keeping docs up to date :)
Chris
---(end of
This patch imlements the TODO that calls for the ability to turn off all
clustering on a table.
Syntax is ALTER TABLE ... SET WITHOUT CLUSTER;
Doc patch plus regression test is included.
Chris
Index: doc/src/sgml/ref/alter_table.sgml
More information on authorization charges.
Original Message
Subject: Re: Re: Cancelling authorization transactions
Date: Thu, 8 Apr 2004 07:13:22 -0700 (PDT)
From: VeriSign Payment Support [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Hello,
Thanks for writing to
Ummm...doh!
Sorry for sending this crap to the list, guys - I guess my mail client
must have expanded an alias in an unexpected way :(
Chris
Christopher Kings-Lynne wrote:
More information on authorization charges.
Original Message
Subject: Re: Re: Cancelling authorization
Other than it's in SQL2003, what's the point of implementing this?
It seems like a mighty marginal feature ...
I don't see a problem with implementing every function that SQL2003
has...isn't that the point of implementing the standard?
Chris
---(end of
Even changing the syntax to qualified_name DROP CLUSTER doesn't work
due to the existence of relation_expr DROP
I have an idea. Change the code to use relation_expr, then throw an
error from gram.y if $$-inhOpt != INH_DEFAULT.
Yeah, that was the plan. I have been too busy (or too lazy more
Hi,
The attached patch adds a new command:
ALTER TABLE [ONLY] foo SET WITHOUT CLUSTER;
I would probably have preferred the DROP CLUSTER syntax, but it doesn't
seem easy to get working without shift/reduce problems.
It has support for inheritance.
I have also fixed the previously detailed
many are using varying[]. Your patch is now in the
archives, and we can point folks to it if they ask.
---
Christopher Kings-Lynne wrote:
Hi,
I know 7.0.x is pretty old, but I'm wondering if we should fix this to
make it better
I submitted a fix for 7.5 dumping 7.0 previously and it was accepted :)
That previous fix was for a different issue...
Oh, it for using a 7.5 dump on a 7.0 database? I didn't think that
would even work. :-)
Yes, it works fine. We still support pg_dumping all 7.x databases.
Anyway, you say the
Duh, sorry. Got confused. I though you weren't the submitter, for some
strange reason. Anyway, I see this in the code:
+ /* Handle array types */
+ if (typname[0] == '_')
+ {
+ isarray = true;
+ typname++;
+ }
Do we know that is always true? What is
What does this patch have to do with ACLs? Wasn't that Fabien's
previous patch?
Chris
Bruce Momjian wrote:
Where are on this? Without a user-visible way of seeing the acl values,
is this still useful?
---
Fabien COELHO
It's not a problem, since that code path is only ever executed when
dumping a 7.0 backend. It's in the MyFormatType function in pg_dump.c
that is used whenever the backend doesn't have its own format_type function.
Right. The patch looked dangerous to me too, until I understood the
context.
Yes, agreed. I think we decided that super-user-only could disable
trigger on a global basis. I prevent folks from mucking with the system
tables to do it.
It should be a per-table thing:
ALTER TABLE blah [ DISABLE | ENABLE ] [ALL | FOREIGN KEY ] TRIGGERS;
Chris
---(end
Doing it with alter table seems to imply that the change is permanent
(eg, the table loses checking), whereas that is most certainly not what
is wanted. With a SET variable it lasts only for the session, and
doesn't have to be reset manually.
Ah, then in that case, how about adding to the
OK, here's the final version of SET WITHOUT CLUSTER. Has docs +
regression test.
Chris
Index: doc/src/sgml/ref/alter_table.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/ref/alter_table.sgml,v
retrieving revision
If you like to live dangerously and not make distclean before you cvs
update, then use a vpath build (separate build tree). There's no reason
to have to maintain a large set of .cvsignore files.
How does one do a vpatch build? (I live dangerously)
Chris
---(end of
Ok, so I guess I can use regressionuser[123], regression[123] as names in
the validation. Writing tests cases is not fun, so I tried to put some fun
by using these characters.
I don't really think it's necessary for the regression tests to test
this functionality.
Once this machinery is in...can
And consider this case:
BEGIN;
...
SAVEPOINT x;
SELECT func_call();
SELECT func_call();
COMMIT;
Now if func_call has a savepoint, it is really nested because it can't
know whether the savepoint X will be used to roll back, so its status is
dependent
I wrote the pg_dump bits, so I guess I can answer these...
And about restore, particularly to another machine, what do we do if the
tablespace can't be created in the location specified in the dump? The
tablespace creation fails, and all objects specified in that tablespace
also fail? Seems bad,
Are we ripping out our initlocation code at the same time?
Not done yet, but it's dead and should be removed as soon as a
decent respect for the deceased permits ;-)
You want me to do the honors?
What about people upgrading from 7.4 databases that used database locations?
Chris
Hi,
Attached is a new backend function, pg_get_serial_sequence. It allows
you get a sequence name in a format suitable for use with the sequence
functions.
Has docs and regression.
I updated pg_dump to use it as well.
Tested against 7.5 and 7.4 backends, with independent and dependent
Does this:
The files belonging to this database system will be owned by user chriskl.
This user must also own the server process.
The database cluster will be initialized with locale C.
The database cluster will be initialized with default encoding UNICODE.
creating directory
Ah, i'm silly. This is a much cleaner implementation of my previous
initdb encoding patch.
Just discard the previous.
Chris
initdb2.txt.gz
Description: GNU Zip compressed data
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
This should save a lot of support requests, hopefully.
I kinda doubt it will save any :-(. In what situation would this not
merely be echoing back what the guy had just specifically typed on the
command line?
When no -E argument is supplied at all, or when they type ISO-8859-1
instead of LATIN1.
Hi,
This is the final patch that adds OWNER TO commands to every object.
This includes tablespaces. I have also added RENAME TO on tablespaces.
Full docs changes are included (+ 3 new files that must be put in
doc/src/sgml/ref).
All new regression tests included also.
Please review and apply
When running pg_dump --clean against a server that doesn't have schemas
the namespace is blank and ends up producing a dump full off things like:
DROP TABLE .tab;
Since the person is dumping using 7.5 pg_dump, presumably they will be
restoring to 7.5, and it should be:
DROP TABLE public.tab;
Hi,
This patch adds the following options to pg_dumpall, to be passed to
pg_dump:
-S, --superuser=NAME
-O, --no-owner
-X disable-dollar-quoting, --disable-dollar-quoting
-X disable-triggers, --disable-triggers
Chris
pg_dumpall.txt.gz
Description: GNU Zip compressed data
OK,
This version works wonderfully on my production database.
Chris
pg_dump_owners2.txt.gz
Description: GNU Zip compressed data
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Hmmm, It doesn't apply cleanly for me...
Chris
Andrew Dunstan wrote:
Would people with older versions of perl ( 5.6 I think ) please try the
attached patch against what is now on cvs for plperl, and let me know if it
compiles, links and runs? (Thanks to Abhijit Menon-Sen for pointing me in
the
I have moved the mention of the dash higher in the TODO file.
Maybe you could put the dash in a different color (red?) so it stands out
more. Or maybe the whole item could go in a different color if done./
Yes, what about stroke through:
Because neither works in the plain text version.
Chris
Attached is an updated ALTER TABLE ... SET TABLESPACE patch.
It uses the block by block copy mechanism proposed by Tom and handles i)
ALTER TABLE index and ii) Copying of TOAST tables and the TOAST
table's index.
It doesn't handle copying of system tables (pg_largeobject) and, in the
Other products, such as wxWindows, have seen quite a lot of Digital Mars
users embrace it once it started supporting DMC++.
That is an extremely poor allegory. wxWindows is a GUI TOOLKIT.
PostgreSQL is an independent database server. 99.999% of our windows
installations will be from the binary
.
---
Christopher Kings-Lynne wrote:
Hi,
This is the final patch that adds OWNER TO commands to every object.
This includes tablespaces. I have also added RENAME TO on tablespaces.
Full docs changes are included (+ 3 new files that must be put in
doc/src/sgml/ref).
All new regression
Please remove that; if I thought either one was a good idea, I would
have allowed it in the committed patch.
Sequences are too small to be worth moving around, and may someday be
reimplemented in a fashion that doesn't use up a separate disk file for
each one. If we allow SET TABLESPACE on them
Does this patch allow setting the tablespace of sequences as well? If
so, then you will need to modify pg_dump of SERIAL sequences. Perhaps
output a ALTER TABLE/SET TABLESPACE command after the CREATE TABLE
definition to move the SERIAL sequence.
The same argument applies if it allows moving
In fact, now that I think of it, the patch-as-committed already
introduces some serious headaches for pg_dump: it can't know for sure
what name will be assigned to constraint indexes (pkey and unique
indexes) so it has no good way to emit ALTER TABLE SET TABLESPACE
commands for those indexes.
I
Otherwise, we need to extend the ADD CONSTRAINT syntax.
Yeah, I was wondering if there was some minimal-impact way to do that.
Oh, or we create ALTER CONSTRAINT :)
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your free space map
Otherwise, we need to extend the ADD CONSTRAINT syntax.
Yeah, I was wondering if there was some minimal-impact way to do that.
Shall I hold off on doing any pg_dump changes then?
Chris
---(end of broadcast)---
TIP 1: subscribe and unsubscribe
This patch fixes the following bugs:
* pg_dump --clean against a pre-7.3 server output drop commands in the
form: DROP .foo; . These will now all be output as: DROP public.foo;
* If you use ALTER USER to set user params on the cluster owner user,
these would not be dumped. This patch will now
Actually, i'm not sure that making it respect -S is the right way to go.
What we really need is an option that specifies the cluster owner on
the new installation.
I will revert that part of this patch and resubmit shortly...
Chris
Christopher Kings-Lynne wrote:
This patch fixes the following
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 to do with the '-S' switch.
It also fixes the other two issues.
Chris
pg_dump_fixes2.txt.gz
Description: application/gunzip
Hmmm, and I need to resurrect the -X use-set-session-authorization flag
for pg_dumpall as well...patch coming soon...
Chris
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Patch applied. Thanks.
thanks - that's wonderful news :-)
However the patch as it went in has a minor cosmetic issues
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 to do
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
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
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
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
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
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.
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
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
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
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
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
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
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
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;
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:
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 my
* 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,
1 - 100 of 163 matches
Mail list logo
