It is a little bit different because a schema, a table or a function are
database application issues and are normally addressed by pg_dump and
pg_restore, although tablespaces are more an administration issue wrt disk
layout and the like, which are likely to be different from one machine to
While fixing the gui for pg_dump and pg_restore, I painfully noticed
there's no option for the password.
After some tests, I found that using the PGPASSWORD environment variable
will do the job. I'm a bit irritated that it's marked deprecated in
the docs, the .pgpass solution isn't a good one
The first is to add a parameter to CREATE TABLESPACE and ALTER TABLESPACE
called RANDOMPAGECOST (or something like that) which allows users to set
the random page cost for a given tablespace. I'm undecided as to whether
they should be able to set the sequential scan cost. That seems
reasonable too
It's deprecated because it's insecure, on platforms where other users can
see the environment variables passed to pg_dump (which apparently is
quite a few variants of Unix). You wouldn't pass the password on the
command line either ...
Painful as .pgpass may be for an admin tool, I do not know of
I'm trying to build RPMS for 7.3.7 but I have a problem.
contrib/earthdistance seems empty, so configure exits with error:
make[1]: Leaving directory
`/usr/src/redhat/SOURCES/postgresql-7.3.7/contrib/dbsize'
make[1]: Entering directory
I'd like to hack it for them but I don't know where \l is called and
defined. Could someone point me where the code is?
src/bin/psql$ grep pg_database *.c
Probably in describe.c
Erm, but what stops them from going:
SELECT * FROM pg_database;
Chris
---(end of
We decided it didn't make much sense to allow the on-row sequences to be
anywhere but the default tablespace.
Hmmm...
I can understand the performance/utility rationale, but I don't like the
lack of orthogonality on principle. I like elegance;-) As a sequence looks
a lot like a table, I guess it
IMVHO, I think the following todo item should make it for 8.0:
Allow database recovery where tablespaces can't be created
When a pg_dump is restored, all tablespaces will attempt to be
created in their original locations. If this fails, the user must
be able to
Hi,
Should be backport the 'fix acls on owner to' on tables to 7.4? The
other acl objects did not have owner to commands in 7.4 IIRC, but the
alter table is definitely broken.
Chris
---(end of broadcast)---
TIP 5: Have you checked our extensive
Ooh, how about the 'there is no security checking on the cluster on
index command' bug?
Chris
Christopher Kings-Lynne wrote:
Hi,
Should be backport the 'fix acls on owner to' on tables to 7.4? The
other acl objects did not have owner to commands in 7.4 IIRC, but the
alter table is definitely
Being able to export to other dbs will get us _more_ users, not less.
Without some type of corresponding import utility that seems logically false.
Nope. Consider it like this. How many companies are going to move to
PostgreSQL from Oracle if they cannot dump their data back to Oracle as
a
should contain.
---
Christopher Kings-Lynne wrote:
Perhaps. I was also thinking that maybe it's time to combine pg_dumpall
and pg_dump into a single utility. At the moment, I can't see how
pg_dumpall can ever have a -Fc option
I think we should add another column to this table:
http://developer.postgresql.org/docs/postgres/errcodes-appendix.html
And explicitly list out all the exception names.
I think that would be clearer and easier than having a paragraph they
need to read that says 'just use underscores'...
Also, I
And I forgot to add:
* Allow dumping/restoring of any number of specific objects and types
Chris
Christopher Kings-Lynne wrote:
OK, everything for pg_dump TODO I can think of:
pg_dump/pg_dumpall/pg_restore
* Add dumping of comments on composite type columns
* Add dumping of comments on index
Yep, a whole section for pg_dump features and bugs would be nice.
Bruce Momjian wrote:
Do you want any of these added to the TODO?
---
Christopher Kings-Lynne wrote:
And I forgot to add:
* Allow dumping/restoring of any number
That should make exporting to other DBs a lot easier. Of course, that
could be cutting our own throat too ...
It won't make any difference to anything. You can already dump in
INSERT format.
Being able to export to other dbs will get us _more_ users, not less.
Chris
The other tablespace problem is if you drop a tablespace that schema in
another db uses, it's broken still I think.
Chris
Bruce Momjian wrote:
Where are we on this?
---
Tom Lane wrote:
Christopher Kings-Lynne [EMAIL
Oh, just the pronunciation that's different then?
Y're rite cobber, c'mon ofer here and check a prawin on tha barbie, mate!
PS: just teasing of course
Of course :) I could make fun of Americans, but where do you start? :)
---(end of broadcast)---
I'll take a swing at making the language a little stronger. We could
also add it as a mailing list hint. Chris, you have any other ideas
where you would like to see it?
Literally in the release notes - that's all that anyone reads of a new
release :) Wherever it says 'upgrading to 8.0 requires
You're talking about the deletion target table. Sorry to mention
the M word again, but MySQL allows deleting from more than one table
at the same time. Should we support that?
No, because it makes no logical sense at all...
Chris
---(end of
(BTW, does a fr_CA version of it have a chance of being accepted? French
here (in Canada) is still a bit different with its own specifics.
Spelling-wise, the most notable difference is having CAPS with accents
where fr_FR normally doesn't have (for corresponding lowercase accented
letters) and
What I mean here is that I think it would be in our best interests to
define the syntax for any new operation to be as easily guessed as
possible. I believe that ALTER INDEX would be more easily guessed by
more people as the means by which one would alter an index's tablespace
than ALTER TABLE,
Can we put in a recommendation in the release notes that people use 8.0
pg_dump to do their dump? I think that will make everyone's upgrades go
much more smoothly, and we will get many fewer complaints.
I don't think many users realise they can use the next version's pg_dump
to upgrade. I
en_BR would be cool, then I don't have to put up with all that American
spelling :)
I thought you'd be looking for en_OZ ...
en_AU, but it's exactly the same as EN_BR, so that's fine :)
Chris
---(end of broadcast)---
TIP 8: explain analyze is your
Hi guys,
Is it safe to update the atttypid of a timestamp column to be a
timestamptz column? I wish to do this on a production database, so I
need to be sure!
Thanks,
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with
Is it safe to update the atttypid of a timestamp column to be a
timestamptz column? I wish to do this on a production database, so I
need to be sure!
Oh, and what about indexes on them? Do I just drop them beforehand and
recreate?
Chris
---(end of
I read this in the release notes:
---
# Database-wide ANALYZE does not hold locks across tables (Tom)
This reduces the potential for deadlocks against other backends that
want exclusive locks on tables. To get the benefit of this change, do
not execute database-wide ANALYZE inside a transaction
I wouldn't try this without running it against a test database copy first.
I've already discovered that a backend change to a column data type like your
describing can disrupt indexes, views, and analyze rows based on the table --
the last time I did such, I ended up having to dump and reload
Hmm...not ALTER INDEX? Now that there's an operation that actually
modifies an index instead of the table itself, should there be an ALTER
INDEX? It would be cleaner and more consistent, IMO...
Errr, unlike all the other uses for alter table and friends? ie:
OWNER TO
RENAME TO
SET TABLESPACE
1. there is no COMMENT ON TABLESPACE support
That's right.
That's deliberate.
Added to TODO:
* Add COMMENT for tablespaces
You may as well make that:
* Add COMMENT ON for all cluster global objects (users, groups,
databases and tablespaces)
Chris
---(end of
Errr, unlike all the other uses for alter table and friends? ie:
OWNER TO
Which changes the attributes of the table...
And indexes.
RENAME TO
Same.
And indexes.
SET TABLESPACE
Which again changes the attributes of the table..
And indexes.
Chris
---(end of
Hi,
I'm looking to find all records in pg_depend that show that some columns
in my db depend on the 'timestamp' type. So I do this:
select * from pg_depend where refclassid=1247 and refobjid=1114;
1257 is the oid of the pg_type table and 1114 is the oid of the
timestamp type.
It returns just
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
OK, I can do this, but I don't think I'll have time for the first beta.
No problem.
Another interesting think I noticed in pg_dump is dumping of LOBs. It
seems to declare a cursor that fetches the blobs and then issues a fetch
1000 to get
Thanks for your response, but this is what I get:
column, Type, and Modifiers
+
Indexes and foreign key contraints.
No triggers.
It lists triggers. Trust me, I wrote it.
The triggers are responsible for checking FK-contraints in other tables,
that use the table I want to list as refering key.
Another interesting think I noticed in pg_dump is dumping of LOBs. It
seems to declare a cursor that fetches the blobs and then issues a fetch
1000 to get the first 1000 lobs. It never seems to execute any further
fetches.
Huh? That's inside a do-loop.
Errr, yeah. Don't know what made me not
listen_addresses is currently defined as a space-separated list of IP
addresses or names. It would be more consistent with the other
list-type GUC parameters to make it a comma-separated list. Any
objections?
Nope.
---(end of broadcast)---
TIP 3:
Hey Tom,
If you've just made this a GUC_LIST_INPUT variable, then you will need
to update the nasty bit of hackiness in pg_dumpall to allow it to be
dumped without error :(
It's line 782 of pg_dumpall.c. I wonder if you will like that code once
you look at it :P
The problem is there's no way
Dumped by what? It's a PGC_POSTMASTER variable, there ain't gonna be
nobody putting it in ALTER DATABASE or ALTER USER.
Oh yeah, sorry wasn't thinking. Same reason I don't bother handling
preload_libraries and friends in pg_dumpall...
The problem is there's no way to know if they're list type
Drat. I grepped for '7.5' and '705', but not for '7, 5' :-(
I am not sure how that file is used but it might require us to repackage
beta1.
Nah, not worth the trouble. Good thing you noticed it before final though.
Maybe you guys should keep a list of all places that need updating and
all
Didn't get any Oracle hits in a quick google, but I did find out that
MySQL spells it USING:
You guys can go to otn.oracle.com and register for free to get access to
all the documentation they've ever written. I've got an account there.
I do get the odd oracle magazine sent to me though...
$ pg_dump -p 5433 test
pg_dump: could not parse ACL list ([0:1]={postgres=UC/postgres,=UC/postgres}) for object
public (SCHEMA)
Ugh. This is an unforeseen side effect of Joe's recent changes to make
array_out emit dimension info.
I think the most reasonable answer is to tweak the ACL code so
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
Using pg_dump from postgresql 7.3.4 I've obtained
a dump file containing a SEQUENCE SET with no
corresponding SEQUENCE. I've seen that this is usually
due to the presence of a table with a 'serial' field,
but since in this case there is no such table I wonder
if this is a bug in pg_dump.
Perhaps.
Also, given this and your previous operator commutator problem, I
strongly suspect that someone has taken an axe to the system catalogs on
your installation and they are very screwy.
Chris
strk wrote:
Using pg_dump from postgresql 7.3.4 I've obtained
a dump file containing a SEQUENCE SET with
Hey Tom,
Did you rate a mention in the Doom 3 readme file? :)
---
4. COPYRIGHT INFORMATION
DOOM 3 is linked with the JpegLib, copyright (c)1991-1998 Thomas G.
Lane/Independent JPEG Group. All rights reserved.
---
Cool :)
Chris
---(end of
If anyone has time to work on docs over the next two days, please show
up on pgsql-docs and let us know what you want to work on. (And of
course it's still open season for bug-fix patches.)
Tom, I haven't had a comment on the 'restoring LOB comments' patch, nor
on the two tablespace failures
Yeah, those are all bug fixes and okay for post-beta I think. But which
two tablespace failures are you thinking of exactly? The last couple
weeks have been a bit of a blur for me...
During the time between the daemon launch and it closing it's file
handles and calling setsid(2) (which some daemons don't do because
they are buggy) any other code running in the same UID could take over
the process via ptrace, fork off a child process that inherits the
administrator tty, and
I think we need to deny changing column types if a function is using the
table type as a return set.
test=# create table test (a int4);
CREATE TABLE
test=# create function test () returns setof test as 'select 1' language
sql;
CREATE FUNCTION
test=# alter table test alter a type bigint;
ALTER
I disagree. There are many cases where it will work, and AFAIK none
in which you'll get worse than an error message. A couple of examples
where it works:
OK, fair enough.
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
What we really need is dependencies within the function body and the
ability to clear the function cache (recompile).
Can the new function validator function for pl/pgsql add dependencies
perhaps?
Chris
---(end of broadcast)---
TIP 6: Have you
I didn't mean about doing this from a front end. I want to disable
nested_loop and hash_join from the backend.
I tried to set the variables (enable_nestloop and enable_hashjoin) in
costsize.c, but this didn't do it.
Turn them off in your postgresql.conf then.
Chris
---(end
If I want the planner/optimizer to always choose merge join when it needs to
join relations. How can I do it ?
You can't, unless in your transaction you set enable_nestloop,
enable_seqscan, etc. all to off except for the join type you want.
Chris
---(end of
We do need to do that, but it will *not* solve this problem. The
scenario that causes the problem is
CREATE TABLESPACE
...
much time passes
...
CHECKPOINT
...
modify tables in tablespace
drop tables in tablespace
DROP
Uh, why is the symlink not going to be there already?
Because we removed it at the DROP TABLESPACE.
Maybe we could avoid removing it until the next checkpoint? Or is that
not enough. Maybe it could stay there forever :/
Chris
---(end of
Operator commutator is itself, and when reading the ascii version
of the dump (produced with -Fc) I see that this has been changed
with what was probably it's oid instead.
Can you paste that ascii from the dump?
Is this a bug in pg_dump ?
How do I tell which pg_dump version produced the dump ?
I'm
--
-- TOC entry 537 (OID 2663955)
-- Name: ~=; Type: OPERATOR; Schema: public; Owner: strk
-- Data Pos: 0
--
CREATE OPERATOR ~= (
PROCEDURE = geometry_same,
LEFTARG = geometry,
RIGHTARG = geometry,
COMMUTATOR = 2663954,
RESTRICT = eqsel,
JOIN = eqjoinsel
);
How about:
\x
I'm not really keen on this idea unless you're eager to make a 5-year
commitment to maintain the code. The load formats of other RDBMSes change
all the time -- MySQL is a particularly egregious example, with 2
incompatible changes in the last year -- and it would become a pain to keep
track.
Depending on how tense you want to be about Oracle compatibility, we
could make people actually write their blocks as above --- that is,
the SAVEPOINT and ROLLBACK commands would be a required part of the
exception-block syntax. They wouldn't actually *do* anything, but
they would make the code
However, we could certainly talk about altering the default behavior
(eg, install becomes install-no-headers and install-all-headers becomes
part of the default install target).
Seems like a good idea to me.
Chris
---(end of broadcast)---
TIP 9: the
People have been complaining (not without reason) that without any
documentation they can hardly test the new PITR code. I have hacked
up and committed some rough docs that should be enough for testing.
They're on-line now at
http://candle.pha.pa.us/main/writings/pgsql/sgml/backup-online.html
and
Changing to a domain and back doesn't do dependencies correctly:
test=# create table parent (a int4);
CREATE TABLE
test=# drop table parent;
DROP TABLE
test=# drop domain dom;
DROP DOMAIN
test=# create table parent (a int4);
CREATE TABLE
test=# create domain dom as bigint;
CREATE DOMAIN
test=#
Some time back I discussed the inclusion of replication (e.g.
postgres-R) into postgres.
One of the technical reasons that I understand against such a move is
the application dependence of replication. PostgresR requires a large
amount of code change in postgres.
All this leads to a bitter taste
test=# begin;
BEGIN
test=# savepoint A;
SAVEPOINT
test=# rollback to a;
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
LOG: server process (PID 45905) was terminated by signal 11
LOG:
I've just found a bit of undesirable functionality which I would call a bug in
pg_dump. I'm not sure everyone would, but we'll see.
Problem: the script which dumps globals such as users (pg_dumpall -g)
involves deleting *all* users from the pg_shadow table via a direct update to
that table.
AFAICS that happens only if you've specified the -c (--clean) option.
Hence, I don't think it's a bug.
Nope, happens even if you don't pass --clean.
Not in CVS tip ... but you're right, older versions did act that way.
Looks like someone addressed this already.
Yeah, was one of my fixes.
Should
I just got an autoreply from David stating he will be away until August
9 if we want this functionality we have to code it ourselves. If not it
can wait until the next major release.
It can wait --- it was submitted after feature freeze anyway, and we
certainly have more than enough other things
item?
---
Christopher Kings-Lynne wrote:
I just got an autoreply from David stating he will be away until August
9 if we want this functionality we have to code it ourselves. If not it
can wait until the next major release
I find this behavior highly undesirable, and consider it a bug.The
globals dump should just add users, and not delete any.
Unless the --clean option is passed, yes I agree with you. The other
issue is that it is silly to have to use pg_dumpall to get the globals.
A person should be able to
Another reason to combine pg_dumpall into pg_dump...
No argument here. Are you thinking of that?
Yeah. Would be a bit of work though.
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
I've been looking at this for a while now, and will probably give it a
go for 7.6/8.
Let me know when you do, I'd be interested in collaborating.
Chris
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Did this get through? Hadn't seen anyone comment on it, and I thought
it was pretty major :P
Christopher Kings-Lynne wrote:
test=# begin;
BEGIN
test=# savepoint A;
SAVEPOINT
test=# rollback to a;
server closed the connection unexpectedly
This probably means the server terminated
OK, we scheduled beta for August 1, and we are close, but we should get
a few more patches in before bundling beta. I have applied all I could
from the patch queue. Tom needs to review the rest.
Oh, and perhaps once the owner/acl fix patch is in, then whoever commits
Fabien's patch to fix
OK, we scheduled beta for August 1, and we are close, but we should get
a few more patches in before bundling beta. I have applied all I could
from the patch queue. Tom needs to review the rest.
Of my three patches, they are all bug fixes, however the USING INDEX
TABLESPACE one should
I'm seeing this:
gmake[4]: Leaving directory `/usr/home/chriskl/pgsql-server/src/port'
gmake[3]: *** No rule to make target `pg_config.o', needed by `pg_config'.
Stop.
gmake[3]: Leaving directory
`/usr/home/chriskl/pgsql-server/src/bin/pg_config'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving
I notice that we can now tick some more stuff off this list:
http://developer.postgresql.org/docs/postgres/unsupported-features-sql99.html
eg. savepoints.
Chris
---(end of broadcast)---
TIP 6: Have you searched our list archives?
I just remembered that although we now have COMMENT ON LARGE OBJECT
oid, we haven't changed pg_dump to dump and restore these comments.
I went ahead and did this, but then realised that I cannot just dump the
comments normally as the oid the lob is assigned when it's restored is
not
Hi Tom,
I have sent you and the list the HTML page from the oracle tech network
describing all of this. However, it seems to have disappeared in to the
void since you don't seem to have received it and it hasn't hit the list
yet.
You can get a free login to access all the oracle docs and
So, as far as you're concerned, there will never ever be an 8.0.
Eventually we'll do the Sun switcheroo and follow release 7.12 by 13.0.
How about 7.5i :)
Chris
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index
This is more features worth mentioning than we've ever had in a single release
before -- and if you consider several add-ons which have been
implemented/improved at the same time (Slony, PL/Java, etc.) it's even more
momentous. If this isn't 8.0, then what will be?
I tend to agree, and
When I run through the acl changing all references from the old owner to
the new owner, should I combine the resulting acls if possible? Because
if the new owner already has some acls on that item, they will end up
with two acls.
If possible ... how painful would it be to do?
I'm pretty close
I got no mail from any of the PostgreSQL lists this morning. That's not
right. Did this mail get through?
Chris
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere
There is a confusing bug in tablespaces. Here is examples:
OK, let's create a table with the 3 possible tablespaces of indexes:
test=# create table test(a int4) tablespace loc;
CREATE TABLE
test=# create unique index test_a_idx on test(a);
CREATE INDEX
test=# create unique index test_a_idx2 on
CREATE TYPE test (a int4, b int4);
COMMENT ON COLUMN test.a IS 'A column';
Seems harmless, but should we allow it?
Actually, currently it's bad because such comments will not be dumped by
pg_dump. Shall I fix pg_dump?
Chris
---(end of
In 7.4.3, my workmate came across the following situation he thought was
odd.
Basically, we want to know why the group by and order by in the outer
query get their variables from the inner query and not the select
parameters in the outer query?
Chris
-- shouldn't the first SELECT query
In 7.4.3, my workmate came across the following situation he thought was
odd.
Basically, we want to know why the group by and order by in the outer
query get their variables from the inner query and not the select
parameters in the outer query?
Ah, don't worry - I get it now :)
Chris
I reckon they could have a crack at implementing SQL2003 recursive
queries (eg. WITH syntax).
Or, SQL2003 ROLLUP and CUBE queries.
But that's just what I want :)
Chris
Bruce Momjian wrote:
I am forwarding this to hackers on behalf of some people who want to
improve PostgreSQL in India.
I suggest
Yeah, but the point was that he was doing an ALTER OWNER and needed to
fix the ACL to match. I thought he claimed to have written the needed
subroutine. I have not yet looked at his patch though.
I think Fabien's owner changing routine will end up being a strict
subset of my routine. I think
It's bizarre how you can comment on columns in composite types!
CREATE TYPE test (a int4, b int4);
COMMENT ON COLUMN test.a IS 'A column';
Seems harmless, but should we allow it?
Chris
---(end of broadcast)---
TIP 6: Have you searched our list
Hi,
Usually i'd ply away at this one until I figured it out, but we're
running out of time :)
If I have the nspForm variable (which is a Form_pg_namespace) struct
pointer, then how do I check if the nspacl field is default (ie.
NULL). This is so I can avoid running DatumGetAclP on it, which
If possible ... how painful would it be to do?
I'm yet to do that part, so I guess I'll find out.
Actually it looks like you'd better, because for example aclupdate
assumes there's only one entry for a given grantor/grantee pair.
OK, many thanks for the prompt reply :)
BTW, are you sure Fabien did
We are already in a features freeze period, or not ?
This isn't a feature, it's a bug...
Chris
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Does anyone object to extending the grammar to allow this?
ALTER TABLE test ADD PRIMARY KEY (a) TABLESPACE foo;
ALTER TABLE test ADD UNIQUE (a) TABLESPACE foo;
CREATE TABLE test (a INTEGER PRIMARY KEY TABLESPACE foo);
CREATE TABLE test (a INTEGER UNIQUE TABLESPACE foo);
This is needed since we can
Yes. This is horribly ugly, and I suspect that you cannot do it
without making TABLESPACE a fully-reserved word.
No, I've already done it and it works just fine. What is your
suggestion then? Just assume the name of the index it will get?
Also, I realised that the pg_get_serial_sequence()
Does anyone object to extending the grammar to allow this?
Yes. This is horribly ugly, and I suspect that you cannot do it
without making TABLESPACE a fully-reserved word.
I note that this seems to be the Oracle syntax:
CONSTRAINT PK_Stock PRIMARY KEY (Company) USING INDEX TABLESPACE
Does anyone object to extending the grammar to allow this?
Yes. This is horribly ugly, and I suspect that you cannot do it
without making TABLESPACE a fully-reserved word.
This suggests a slightly different oracle syntax. I guess the word
'index' is optional.
Since we stole tablespaces from Oracle, maybe we should make them work
the same?
I never really considered oracle's implementation of tablespaces when I
worked on tablespaces. The database default tablespace seems similar to
Oracle's SYSTEM tablespace. I'm not sure if they use a global tablespace
I never really considered oracle's implementation of tablespaces when I
worked on tablespaces. The database default tablespace seems similar to
Oracle's SYSTEM tablespace. I'm not sure if they use a global tablespace
like we do.
My point was that Oracle has added a tablespace clause to the
That gives us enough to talk through and begin some testing.
Anybody have any other horror stories, bring 'em on.
I think that the PITR docs will have to be written in two sections. One
will need to be a pure reference that orthogonally describes the
options, etc. The other section will need
The solution I had in mind was for ALTER OWNER to run through the ACL
and replace the old owner ID with the new one wherever the old one
appears, in both grantor and grantee positions. So in your example
{chriskl=arwdRxt/chriskl,other=r/chriskl}
becomes
501 - 600 of 2006 matches
Mail list logo
