inner join and ambiguous columns

[Manlio Perillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.

Here is a simple example of using joins in SQLAlchemy:

from sqlalchemy import schema, types, sql, create_engine

metadata = schema.MetaData()
x = schema.Table(
'x', metadata,
schema.Column('id', types.Integer, primary_key=True),
schema.Column('x', types.Text, nullable=False)
)

y = schema.Table(
'y', metadata,
schema.Column('id', types.Integer, primary_key=True),
schema.Column('y', types.Text, nullable=False),

schema.ForeignKeyConstraint(['id'], [x.c.id])
)

engine = create_engine('sqlite://')
engine.create(metadata)

try:
engine.execute(x.insert(), id=1, x='X')
engine.execute(y.insert(), id=1, y='Y')

query = sql.join(x, y).select()
r = engine.execute(query).fetchone()

print r['id']
finally:
engine.drop(metadata)

This code will raise an:
sqlalchemy.exc.InvalidRequestError: Ambiguous column name 'id' in result
set! try 'use_labels' option on select statement.

Now, I would like to avoid using labels, since it will make code much
more verbose.

What is the reason why SQLAlchemy is including the `id` column two times?
After all, it should know that the `id` column is being used for the join.

In plain SQL (Postgresql database):

manlio=> select * from x NATURAL JOIN y;
id | x | y
- ----+---+---
1 | X | Y
(1 riga)

manlio=> select * from x JOIN y USING (id);
id | x | y
- ----+---+---
1 | X | Y
(1 riga)

the `id` column is being added only one time, as it should be.

Thanks Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkt62u8ACgkQscQJ24LbaUQGkwCfa/cSeg9xk1AFHTqTuDrA+LPt
aREAn0SiG75RNFav7cBv2M0Cacu2iyUx
=I+f+
-----END PGP SIGNATURE-----

[Michael Bayer]

send fold_equivalents=True to join().select(). This flag has been
deprecated for awhile but I suppose it is harmless if you truly have a use
case for it (i.e. i will consider un-deprecating it, i didnt think anyone
would ever need it).

>

> Now, I would like to avoid using labels, since it will make code much
> more verbose.
>
> What is the reason why SQLAlchemy is including the `id` column two times?
> After all, it should know that the `id` column is being used for the join.
>
> In plain SQL (Postgresql database):
>
> manlio=> select * from x NATURAL JOIN y;
> id | x | y
> - ----+---+---
> 1 | X | Y
> (1 riga)
>
> manlio=> select * from x JOIN y USING (id);
> id | x | y
> - ----+---+---
> 1 | X | Y
> (1 riga)
>
> the `id` column is being added only one time, as it should be.
>
>
> Thanks Manlio
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkt62u8ACgkQscQJ24LbaUQGkwCfa/cSeg9xk1AFHTqTuDrA+LPt
> aREAn0SiG75RNFav7cBv2M0Cacu2iyUx
> =I+f+
> -----END PGP SIGNATURE-----
>

> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To post to this group, send email to sqlal...@googlegroups.com.
> To unsubscribe from this group, send email to
> sqlalchemy+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.
>
>

[Manlio Perillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Bayer ha scritto:
> Manlio Perillo wrote:
> [...]

> query = sql.join(x, y).select()
> r = engine.execute(query).fetchone()

> [...]

>
> This code will raise an:
> sqlalchemy.exc.InvalidRequestError: Ambiguous column name 'id' in result
> set! try 'use_labels' option on select statement.
>
>> send fold_equivalents=True to join().select(). This flag has been
>> deprecated for awhile but I suppose it is harmless if you truly have a use
>> case for it (i.e. i will consider un-deprecating it, i didnt think anyone
>> would ever need it).
>

Well, the use case it to avoid the use of:
1) use_labels
2) ad hoc column names, to avoid ambiguous columns
3) explicit labels

Unfortunately, fold_equivalents is not a generic solution for me
I have a generative query, where I later add the select_from object.

The query is generative, since the tables involved are not know in advance.
I have several plugins, that take a query instance as input, and return
the (modified) query, and the additional tables involved.
These tables are later joined together.

> [...]

Thanks Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkt65DsACgkQscQJ24LbaUR98wCfctnfwAHUHsnJ1j9pskhp6u5z
MtwAnixPKZqMg9VzCtdTOlLAO0dN4AGu
=8qMv
-----END PGP SIGNATURE-----

[Michael Bayer]

I don't understand what you want then. the flag is applied at the point
of select() where the list of columns that will be in its columns clause
is passed, and then its fixed...unless you're adding columns after the
fact (an unusual pattern). Feel free to look at its implementation and
suggest what it is you're looking for.

>
>> [...]
>
>
> Thanks Manlio
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkt65DsACgkQscQJ24LbaUR98wCfctnfwAHUHsnJ1j9pskhp6u5z
> MtwAnixPKZqMg9VzCtdTOlLAO0dN4AGu
> =8qMv
> -----END PGP SIGNATURE-----
>

[Manlio Perillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Bayer ha scritto:
> [...]

> Unfortunately, fold_equivalents is not a generic solution for me
> I have a generative query, where I later add the select_from object.
>
> The query is generative, since the tables involved are not know in
> advance.
> I have several plugins, that take a query instance as input, and return
> the (modified) query, and the additional tables involved.
> These tables are later joined together.
>
>> I don't understand what you want then. the flag is applied at the point
>> of select() where the list of columns that will be in its columns clause
>> is passed, and then its fixed...unless you're adding columns after the
>> fact (an unusual pattern).

Here is the code I have:
http://paste.pocoo.org/show/178959/

What each plugin do is:
- - add additional columns in the select list
- - add additional where clauses or order_by clauses

Basically I have a simple table inheritance scheme, where each
additional table "derive" from the `contents` table,

> Feel free to look at its implementation and
>> suggest what it is you're looking for.
>

I think I need to refactor that code.
Each plugin *must not* add columns; instead the columnn to add should be
computed using the util.folded_equivalents if tables are joined.

So I think that I simply need the util.folded_equivalents function, thanks.

Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkt6+ukACgkQscQJ24LbaURAtACcC2jVBx4GEc04Yb8Yckbvpve6
eh4An16RWuv9gwfpfj7Vc4rreXBcSogU
=UsZP
-----END PGP SIGNATURE-----

[Michael Bayer]

Manlio Perillo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

> Here is the code I have:
> http://paste.pocoo.org/show/178959/
>
> What each plugin do is:
> - - add additional columns in the select list
> - - add additional where clauses or order_by clauses

I don't see how you are getting column conflicts with that recipe:

http://paste.pocoo.org/show/179031/

>
> Basically I have a simple table inheritance scheme, where each
> additional table "derive" from the `contents` table,
>
>
>> Feel free to look at its implementation and
>>> suggest what it is you're looking for.
>>
>
> I think I need to refactor that code.
> Each plugin *must not* add columns; instead the columnn to add should be
> computed using the util.folded_equivalents if tables are joined.
>
> So I think that I simply need the util.folded_equivalents function,
> thanks.
>
>
> Manlio
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkt6+ukACgkQscQJ24LbaURAtACcC2jVBx4GEc04Yb8Yckbvpve6
> eh4An16RWuv9gwfpfj7Vc4rreXBcSogU
> =UsZP
> -----END PGP SIGNATURE-----
>

[Manlio Perillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Bayer ha scritto:

> Manlio Perillo wrote:
> Here is the code I have:
> http://paste.pocoo.org/show/178959/
>
> What each plugin do is:
> - add additional columns in the select list
> - add additional where clauses or order_by clauses
>
>> I don't see how you are getting column conflicts with that recipe:
>

Because each plugin added the additional tables used in the query select
list:

def get_content_article_by_slug(environ, content_type, query):
tables = [schema.content_article, schema.categories]

query = query.column(schema.content_article)
query = query.column(schema.categories)

return query, tables

I have refactored the code and now it works without problems.
I use both the select method on the Join instance (when the plugins does
not need to modify the query object), and the util.folded_equivalents
function by hand.

I have read the ticket 1131, and it seems that the folded_equivalents
function was used, in the ORM, for exactly the same reason as I'm doing now.

So, it seems that nobody is doing this without using the ORM.
Is it a problem to revoke the deprecation on the folded_equivalents?
I don't think I can go without it.

Thanks Manlio

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkt7Gc8ACgkQscQJ24LbaUTztQCcC//niqKT21umxaKCXEy4kcPl
mWYAoIP4k2kh4awv7EuJgppKwS1jXu/1
=45t9
-----END PGP SIGNATURE-----

[Michael Bayer]

Manlio Perillo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Bayer ha scritto:
>> Manlio Perillo wrote:
>> Here is the code I have:
>> http://paste.pocoo.org/show/178959/
>>
>> What each plugin do is:
>> - add additional columns in the select list
>> - add additional where clauses or order_by clauses
>>
>>> I don't see how you are getting column conflicts with that recipe:
>>
>
> Because each plugin added the additional tables used in the query select
> list:
>
> def get_content_article_by_slug(environ, content_type, query):
> tables = [schema.content_article, schema.categories]
>
> query = query.column(schema.content_article)
> query = query.column(schema.categories)
>
> return query, tables

just so I can understand fully can you modify the paste I sent to
illustrate exactly how the results are happening, as that can help me to
formulate the best version of this feature.

and yes the function is used in the ORM for the case where its
inconvenient to use use_labels, specifically here where the old
polymorphic_union function matches things up on column names. That
function isn't needed except for a very fringe use case, which I
eventually want to roll into a more flexible polymorphic system that
wouldn't need to use UNION with joins.

>
>
> I have refactored the code and now it works without problems.
> I use both the select method on the Join instance (when the plugins does
> not need to modify the query object), and the util.folded_equivalents
> function by hand.
>
>
> I have read the ticket 1131, and it seems that the folded_equivalents
> function was used, in the ORM, for exactly the same reason as I'm doing
> now.
>
> So, it seems that nobody is doing this without using the ORM.
> Is it a problem to revoke the deprecation on the folded_equivalents?
> I don't think I can go without it.
>
>
>
> Thanks Manlio
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkt7Gc8ACgkQscQJ24LbaUTztQCcC//niqKT21umxaKCXEy4kcPl
> mWYAoIP4k2kh4awv7EuJgppKwS1jXu/1
> =45t9
> -----END PGP SIGNATURE-----
>

[Manlio Perillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Bayer ha scritto:
> [...]

>> just so I can understand fully can you modify the paste I sent to
>> illustrate exactly how the results are happening, as that can help me to
>> formulate the best version of this feature.
>

I have pasted a complete working fragment of the code I have used:
http://paste.pocoo.org/show/179089/

By the way, I still have a problem when using fold_equivalents.
http://paste.pocoo.org/show/179092/

Again, the plain SQL code does not show duplicate columns here:

wsgix=> select * from content_types NATURAL JOIN contents
NATURAL JOIN content_articles
NATURAL JOIN categories WHERE slug='python';
type | category_slug | slug
- ---------+---------------+--------
article | programming | python
(1 riga)

Thanks Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkt7MzQACgkQscQJ24LbaUQSIACeMnH/OGepSOJrVpnMZYvUNo7O
pu0An0GE4BUNGHaLAyuI+frAbuEm5dFw
=/13b
-----END PGP SIGNATURE-----

[Michael Bayer]

On Feb 16, 2010, at 7:07 PM, Manlio Perillo wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Bayer ha scritto:
>> [...]
>>> just so I can understand fully can you modify the paste I sent to
>>> illustrate exactly how the results are happening, as that can help me to
>>> formulate the best version of this feature.
>>
>
> I have pasted a complete working fragment of the code I have used:
> http://paste.pocoo.org/show/179089/
>
>
> By the way, I still have a problem when using fold_equivalents.
> http://paste.pocoo.org/show/179092/

the feature would be built into the select(), that as each column is added, if a column of the same name exists and is related by a foreign key, it is skipped.

It shouldn't be hard for you to temporarily work this in as a preliminary step each time you call the column() method. You could probably even make a subclass of Select() that does it.

This is one reason fold_equivalents is deprecated. Its not that hard to roll yourself. But it can be built into select() at some point which is a better place for it to be than in join().

>
>
> Again, the plain SQL code does not show duplicate columns here:
>
> wsgix=> select * from content_types NATURAL JOIN contents
> NATURAL JOIN content_articles
> NATURAL JOIN categories WHERE slug='python';
> type | category_slug | slug
> - ---------+---------------+--------
> article | programming | python
> (1 riga)
>
>
>
>
> Thanks Manlio
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkt7MzQACgkQscQJ24LbaUQSIACeMnH/OGepSOJrVpnMZYvUNo7O
> pu0An0GE4BUNGHaLAyuI+frAbuEm5dFw
> =/13b
> -----END PGP SIGNATURE-----
>

[Manlio Perillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Bayer ha scritto:
> On Feb 16, 2010, at 7:07 PM, Manlio Perillo wrote:
>
> Michael Bayer ha scritto:
>>>> [...]
>>>>> just so I can understand fully can you modify the paste I sent to
>>>>> illustrate exactly how the results are happening, as that can help me to
>>>>> formulate the best version of this feature.
> I have pasted a complete working fragment of the code I have used:
> http://paste.pocoo.org/show/179089/
>
>
> By the way, I still have a problem when using fold_equivalents.
> http://paste.pocoo.org/show/179092/
>
>> the feature would be built into the select(), that as each column is added,
>> if a column of the same name exists and is related by a foreign key,
it is skipped.
>

I agree.
It should be built into the select.

By the way, I have found an incorrect behaviour in SQLAlchemy, when the
select column list is empty.

query = sql.select(
None, contents.c.slug == 'python', from_obj=[join])

SQLAlchemy generates an incorrect SQL query.
It should, instead, automatically add the columns from the `from_obj`
list, skipping duplicate columns involved in a join.

Can I fill a bug report for this?

Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkt79f0ACgkQscQJ24LbaUSr/gCfatYVT36ZvK+0prqXKVcck4sI
e3YAnjgvwvi/d5qUT17gOx8DopvJvLPN
=IdpF
-----END PGP SIGNATURE-----

[Michael Bayer]

sounds more like an assumption to me. select(None) is specifically a select with no columns, which can be added later using column() (that might be the intent).

>
>
> Can I fill a bug report for this?
>
>
> Manlio
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkt79f0ACgkQscQJ24LbaUSr/gCfatYVT36ZvK+0prqXKVcck4sI
> e3YAnjgvwvi/d5qUT17gOx8DopvJvLPN
> =IdpF
> -----END PGP SIGNATURE-----
>

[Manlio Perillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Bayer ha scritto:
> [...]

> By the way, I have found an incorrect behaviour in SQLAlchemy, when the
> select column list is empty.
>
> query = sql.select(
> None, contents.c.slug == 'python', from_obj=[join])
>
>
> SQLAlchemy generates an incorrect SQL query.
> It should, instead, automatically add the columns from the `from_obj`
> list, skipping duplicate columns involved in a join.
>
>> sounds more like an assumption to me.
>> select(None) is specifically a select with no columns,
>> which can be added later using column() (that might be the intent).

Of course.
The columns should be added when the SQL query is generated.

P.S.:
it seems that your MUA has problems wrapping the text

Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkt8A7UACgkQscQJ24LbaUQ/hwCdE5kfYXs92cR1AxFlXWd0yLAl
GG4AnA7kFRTJ9WVnXDmY+dJ+kfgdxxiS
=VLzc
-----END PGP SIGNATURE-----

[Michael Bayer]

On Feb 17, 2010, at 9:56 AM, Manlio Perillo wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Bayer ha scritto:
>> [...]
>> By the way, I have found an incorrect behaviour in SQLAlchemy, when the
>> select column list is empty.
>>
>> query = sql.select(
>> None, contents.c.slug == 'python', from_obj=[join])
>>
>>
>> SQLAlchemy generates an incorrect SQL query.
>> It should, instead, automatically add the columns from the `from_obj`
>> list, skipping duplicate columns involved in a join.
>>
>>> sounds more like an assumption to me.
>>> select(None) is specifically a select with no columns,
>>> which can be added later using column() (that might be the intent).
>
> Of course.
> The columns should be added when the SQL query is generated.

yeah that's not how it works. the columns are added to the structure. statement compilation doesn't make huge guesses like that.

>
>
> P.S.:
> it seems that your MUA has problems wrapping the text
>
>
> Manlio
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkt8A7UACgkQscQJ24LbaUQ/hwCdE5kfYXs92cR1AxFlXWd0yLAl
> GG4AnA7kFRTJ9WVnXDmY+dJ+kfgdxxiS
> =VLzc
> -----END PGP SIGNATURE-----
>

[Manlio Perillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Bayer ha scritto:
> On Feb 17, 2010, at 9:56 AM, Manlio Perillo wrote:
>
> Michael Bayer ha scritto:
>>>> [...]
>>>> By the way, I have found an incorrect behaviour in SQLAlchemy, when the
>>>> select column list is empty.
>>>>
>>>> query = sql.select(
>>>> None, contents.c.slug == 'python', from_obj=[join])
>>>>
>>>>
>>>> SQLAlchemy generates an incorrect SQL query.
>>>> It should, instead, automatically add the columns from the `from_obj`
>>>> list, skipping duplicate columns involved in a join.
>>>>
>>>>> sounds more like an assumption to me.
>>>>> select(None) is specifically a select with no columns,
>>>>> which can be added later using column() (that might be the intent).
> Of course.
> The columns should be added when the SQL query is generated.
>
>> yeah that's not how it works. the columns are added to the structure. statement compilation doesn't make huge guesses like that.
>

Ok.
My idea was to implement the equivalent of SQL '*' column.
I can't use the literal '*' in the select column list, since it will
disable (?) SQLAlchemy type system.
And I don't want to manually add the columns, since I will end up with
duplicate columns.

Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkt9Hi0ACgkQscQJ24LbaURw+ACcDmBfcJTZyJJtn3w7Iw02tUY6
bZAAnAr+m0GNB2pwn/uQFxjHibvaTGpB
=9462
-----END PGP SIGNATURE-----

[Michael Bayer]

that's a better idea. how about sqlalchemy.EXPAND_STAR ?

>
>
>
> Manlio
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkt9Hi0ACgkQscQJ24LbaURw+ACcDmBfcJTZyJJtn3w7Iw02tUY6
> bZAAnAr+m0GNB2pwn/uQFxjHibvaTGpB
> =9462
> -----END PGP SIGNATURE-----
>

[Michael Bayer]

On Feb 18, 2010, at 10:18 AM, Michael Bayer wrote:

Ok.

My idea was to implement the equivalent of SQL '*' column.

I can't use the literal '*' in the select column list, since it will

disable (?) SQLAlchemy type system.

And I don't want to manually add the columns, since I will end up with

duplicate columns.

that's a better idea.   how about sqlalchemy.EXPAND_STAR ?

although, still not a compiler level thing.   you still want to be able to say "select.c.<colname>".  So it would occur at the point of objects being added to the FROM list.

[Manlio Perillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Bayer ha scritto:
>

> On Feb 18, 2010, at 10:18 AM, Michael Bayer wrote:
>
>>>
>>> Ok.
>>> My idea was to implement the equivalent of SQL '*' column.
>>> I can't use the literal '*' in the select column list, since it will
>>> disable (?) SQLAlchemy type system.
>>> And I don't want to manually add the columns, since I will end up with
>>> duplicate columns.
>>
>> that's a better idea. how about sqlalchemy.EXPAND_STAR ?
>
> although, still not a compiler level thing. you still want to be able
> to say "select.c.<colname>". So it would occur at the point of objects
> being added to the FROM list.
>

Right.
A direct support for the special '*' column is better, and in SQL you
can still specify additional columns in addition to '*'.

As for the name to use, EXPAND_STAR is ok.
The only alternative I can think about is something like
sqlalchemy.schema.COLUMN_ALL.

Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkt9anIACgkQscQJ24LbaUTn0gCff3M4sFUoRz2xV//qYeKjTlLw
fJkAn1AK19mS5B4/4ZLk8mjDSRTyDRc4
=wu+0
-----END PGP SIGNATURE-----