not exactly uncommon for tools like ecpg to not worry
about memory. After all it gets freed when the program ends.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
gt; whom can I discuss it?
Feel free to send it to me.
Thanks,
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Hi,
> I have a modified version of ECPG, to which I gave the ability to
> do semantic analysis of SQL statements. Where i can share it or with
> whom can I discuss it?
Feel free to send it my way.
Thanks,
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (D
-fixable
> ECPGColLabelCommon uses and adds a hard-wired special case for
> STRING to handle the var_type usage.
I'm fine with this approach.
Thanks Tom.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
accept to not
test this particular feature and remove the warning? After all this is
not the way the statement should be used, hence the warning. Or should
be keep it in and redirect the warning? In that case, we would also
lose other warnings that are not planned, though.
Any comments?
Michael
--
by you then I accept that. After all, the reason we
> want you to deal with this is not only that you made the original
> commit
> but because you're the expert in this area.
I will commit the patch(es). Thanks.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
QL DEALLOCATE PREPARE stmt_2;
>
> And DEALLOCATE is far from being new.
I'm not sure I understand. Any usage of DECLARE STATEMENT makes the
file need the current version of ecpg anyway. On the other hand
DEALLOCATE did not change its behavior if no DECLARE STATEMENT was
issued, or what
final
decision whether we commit Kuroda-san's patches?
They are fine by me. Another pair of eyes would be nice, though. maybe
you could have another look, Horiguchi-san?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
te with someone,
> unless someone asks.
Completely agreed, my point was that documenting the process to some
extend would be helpful. For obvious reasons I'm the wrong person to do
that, though. :)
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|
> I do think all committers need to understand the role of the RMT so
> they
> can respond appropriately. Do we need to communicate this better?
Being the one who assumed a different procedure, yes please. :)
Thanks,
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at M
can use EXEC SQL AT ... DESCRIBE ...;
already anyway. Again, not very meaningful but why should we accept a
connection one way but not the other?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
signature.asc
Description: This is a digitally signed message part
t, too.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
ou on an ecpg
> issue. Not sure if that was before or after Peter's email.
I think that was before, at that point I still thought it was nothing
time sensitive. And unfortunately it didn't register that RMT was
involved at all.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Mic
o think it through,
the original issue that kind of started this whole mess.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
ort answer, the less confidence they
> have
> in this getting resolved in a timely manner.
Again agreed, please keep in mind, though, that I didn't notice I was
being chased until Peter's first email.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
ink we can change
anything for the worse by doing that. And other databases are not
really strict about this either.
> I would be interested in hearing your view, and that of others, on
> whether this is really a bug at all.
I think the question is more which version of the patch we commit
email about it, why did
> you
> commit it in the first place? I just don't understand this at all.
I'm getting very tired of you accusing me of things I neither said nor
did. Please stop doing that or show me the email where I said the patch
was "inconsequential"? As for
ms in
> this
> way as a necessary evil. Something to be avoided at all costs. Why
> should people that don't know anything about ecpg make decisions
> about
> ecpg? In general they should not.
Well, you did lay out what the decision would be and I fully agreed
with it. So again
s.
Fully agreed. That's why a short glance at the patch didn't suffice to
answer this. I didn't see any issues with the patch so far. Please send
it to me once its finished (or is it already?) and I'll give it a run,
too.
Hopefully I caught up on all emails and didn't miss part
first conversation that brought up the time issue was your email
that started this thread. There you set a deadline which I understand
and accept. But then I never said a word against it, so the question
remains, why accusing me of something I never did?
> Again, the scope of what you're comp
On Sat, 2021-08-07 at 15:31 -0700, Peter Geoghegan wrote:
> On Sat, Aug 7, 2021 at 12:43 PM Michael Meskes
> wrote:
> > Again, I didn't know the RMT was expecting anything from me. Yes, I
> > knew I needed to spend some time on a technical issues, but that's
> >
e
> status update?
Where did I say I expect you to wait? How could I even do that given
that I didn't even know you were waiting for a status update from me?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Hi Peter,
> The RMT continues to be concerned about the lack of progress on this
> open item, especially the lack of communication from Michael Meskes,
> the committer of the original patch (commit ad8305a). We are prepared
> to exercise our authority to resolve open items direct
All,
> between DECLARE and the past queries qualify as an open item. I am
> adding Michael Meskes in CC. I got to wonder how much of a
> compatibility break it would be for DEALLOCATE and DESCRIBE to handle
> EXEC SQL AT in a way more consistent than DECLARE, even if these are
&g
even aware it's on
there. While I agree that it makes debugging of memory handling in ecpg
more difficult, I don't see much of a point in it.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
> This patch has now been silent for quite a while, unless someone is
> interested
> enough to bring it forward it seems about time to close it.
I am interested but still short on time. I will definitely look into it
as soon as I find some spare minutes.
Michael
--
Michael Meskes
Micha
le test case,
or in other words, if you ask me go ahead with your patch.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
's obviously way too late for 12. Sorry for the
noise.
In this case I'd like to details about what is wrong with the
implementation.
Thanks.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: micha
mpatible where possible.
> In order to modify bugs, I think many designs, implementations,
> and specifications should be changed.
I hope the authors of said patch speak up and explain why they
implemented it as is.
> Is it acceptable for PG12?
In general absolutely.
Michael
--
Michae
Hi,
> Memory leaks occur when the ecpg_update_declare_statement() is called
> the second time.
> ...
I'm going to commit this patch HEAD, this way we can see if it works as
advertised. It does not hurt if it gets removed by a rewrite.
Thanks for finding the issue,
Michael
--
t spends more time for implementing. Do you have any advice?
> ...
Unfortunately no, I have no advice. Originally all statements needed
this treatment. :)
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber
ust not want this test to be run by default, and thus I
> > should
> > add "make -C src/interfaces/ecpg/test checktcp" to
> > coverage.pg.org's
> > shell script?
>
> I believe it's intentionally not run by default because it opens up
> an extern
igured worse case we can revert the patch if people object.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux
> None here. You might want to get it in in the next 12 hours or so
> so you don't have to rebase over a pgindent run.
Thanks for the heads-up Tom, pushed.
And thanks to Matsumura-san for the patch.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|
multi-bytes encoding environment, a part of character of
> message is cut off.
>
> It may be very difficult to fix. I pretend I didn't see it for a
> while.
> ...
Hmm, any suggestion?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
> allocated
> by both PREPARE FROM and PREPARE AS under the following
> constraints:
> - It must not include a using-clause.
> - The statement name must follow to the specification of PREPARE
> AS.
This look very reasonable to me. I'm completely fine with this
restriction b
Hi,
> I have found a potential memory overflow in ecpg preproc module.
> ...
Thanks for finding and fixing, committed.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot mesk
merge.
Thanks.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
top of
> > my head. Need to check when I'm online again.
>
> I will also consider it.
Thank you.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot or
id that if we
do not merge the approaches, we will run into issues later. There was a
reason why we added PQprepare, but I do not remember it from the top of
my head. Need to check when I'm online again.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|
> I attached a simple bug-fixing patch.
I'm not happy with the situation, but don't see a better solution
either. Therefore I committed the change to get rid of the regression.
Thanks.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|O
an throwing an error continue
> executing statement "CLOSE cur_name" with ecpg_do().
The problem as I see it is that the cursor is known to the backend but
not the library. Takaheshi-san, Hayato-san, any idea how to improve the
situation to not error out on statements that used to wor
This also seems to be conflicting with
bd7c95f0c1a38becffceb3ea7234d57167f6d4bf. If we want to keep this
commit in for the release, I think we need to get these things fixed.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql
e. This
cannot be done with an addon. Please see the attached for a way to do
this, untested though.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Bar
Hi Matsumura-san,
> I will read README.parser, ecpg.addons, and *.pl to understand.
Feel free to ask, when anything comes up.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot mes
ing function in ecpglib.
> Is it good?
I'd say so.
Thanks.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
re
> converted to "$1" and ECPGdo() cannot distinguish them.
> Therefore, ECPG should produce different code.
I agree. It seems that stuff really broke over the years and nobody
noticed, sigh.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Co
27;s not worth it. We all know where the grammar is and that the
ecpg tools only parse that one file. Why putting effort into writing it
down too?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
EXECUTE test_prep (:i) INTO :ID;".)
Ok, thanks. That means the parser has to handle the list of execute
arguments differently, which in hindsight is pretty obvious.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) do
is that constants in this subtree are move to the
output literally instead treated as parameters.
Thanks.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Fo
ch as "EXEC SQL
> EXECUTE test_prep (2);"
Correct.
As for the PREPARE statement itself, could you try the attached small
patch please.
This seems to create the correct ECPGPrepare call, but I have not yet
tested it for many use cases.
Thanks.
Michael
--
Michael Meskes
Michael at Fam
Matsumura-san,
> Maybe, there is no work-around.
Did you analyze the bug? Do you know where it comes from?
> For supporting it, there are two steps.
Could you please start with explaining where you see the problem? I'm
actually not sure what you are trying to do here.
Michael
And yes, it does look like a bug to me, or better like changes in the
backend that were not synced to ecpg.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! F
n I think your patch does not notice
the end of the rule.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
r than I expected. Thanks. My first test
show two "missing" semicolons in gram.y. :)
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF
does. There has to be a way for the script to find the end of a
rule and I wonder if bison's way can be used in such a simple perl
script too.
> I think we need to fix that script to either cope with missing
> semicolons,
> or at least complain about them. Too tired to look into how,
Hi Higuchi-san,
> I updated and attached the patch. As I show in previous post, this
> version is that "IF NOT EXISTS" keyword and variable for "WITH NO
> DATA" are added to ecpg.trailer.
Thank you, committed.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot
Matsumura-san,
> I attach a new patch.
> ...
Thank you so much.
This looks very good. Committed to HEAD.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot o
mmerror(PARSE_ERROR, ET_ERROR, "CREATE
> TABLE AS cannot specify INTO");
> +
> + $$ = cat_str(7, mm_strdup("create"), $2,
> mm_strdup("table if not exists"), $7, mm_strdup("as"), $10, $11);
> }
>
hrough ecpg. The
whole change of this rule has been made to make sure this syntax is not
accepted.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
don't think this will help much, don't bother.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
descriptor_item.data_len)
Isn't that a better way then? This looks more smoothly to me.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
well not see the obvious.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
nge ECPGset_desc() to not use ecpg_store_input() in case of an
bytea. This looks odd to me. Can you please explain that to me?
Thanks
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot me
code is handled by the
preprocessor and replaced by a struct definition anyway.
Feel free to remove.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia
> I like having a hard limit on the number of loop iterations;
> that should ensure that the test terminates no matter how confused
> ecpglib is.
I get your point and thus will only clean up the tests a little bit.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at M
ices, but wouldn't it be a better
> idea
> to break out of the loop on seeing an error?
I wonder if it would be better to make the test cases use the proper
whenever command instead. That would give us a slightly better
functionality testing I'd say.
Michael
--
Michael Meskes
Mic
threaded apps, but I didn't see any obvious reason to think so,
> so I changed it too.
Thanks Tom.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia!
outright. I don't see
> anything so wrong with just documenting the hazard. The situation
Actually I meant using setlocale() and documenting that it must not be
used with threads, or document it must not be used with locales?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Mic
t; more likely to fail when they do.
The question is, what do we do on those platforms? Use setlocale() or
fallback to (a) and document that ecpg has to run in a C locale?
We could also rewrite the parsing of numbers to not be locale
dependent.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De
to just remove that code and document that you'd better run ecpg
> in LC_NUMERIC locale, but it'd be nice if we could do better.
How about attached patch? According to my manpages it should only
affect the calling threat. I only tested it on my own system so far.
Could you please
ot know it.
I'm at a loss here. I don't understand what you are trying to say.
An incompatible change is ok if we change the version number of the
library accordingly.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
unter their unknown type(=ECPG.bytea) in
> sqlvar_struct.sqltype.
You mean if they are not recompiled? If so, yes, how else could that be
handled?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber
lso have in our test suite. I'm afraid this will come back to haunt
us.
> > The patch does not support ECPG.bytea in sqltype of "struct
> > sqlvar_struct"
> > because of compatibility.
Sorry I do not really understand what you mean. Could you please
explain?
Michael
dard? I don't really
see where the usability drawback is. In general I would prefer being as
close to the standard as reasonably possible.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael a
should try to stick with
the standard and, if it does not comment on it, with what others in the
market do to make migrations easier. So far I do not remember any
database having a bytea datatype in embedded SQL.
Comments anyone?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at M
out there with a Windows system who could bisect the
tree and find which commit is the culprit? Or did we have any changes
to the buildfarm scripts that may be causing this?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgres
> The attached patch corrects the cursor name.
Fixed, thanks for the patch.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers!
ting and fixing. I will push the patch as soon as I'm
online again.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
es, but if it compiles
cleanly I'm fine either way. I'm assuming you're talking about
including the files for compiling ecpg, not as externally visible
header files, right?
michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|P
nd conflict resolution will do the
trick. But thanks for the heads-up.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! SF 49ers! Use Debian GNU/Linux, PostgreSQL
t, though. :)
> If accepted, this bug fix can be back ported to earlier versions of
> ecpg as well.
As usual this will be done after a couple of days, if no problems
appear. I'm pretty sure there won't but sticking to my workflow here.
Michael
--
Michael Meskes
Michael at Fa
82 matches
Mail list logo
