that it will get accepted but I
will be arguing for it.
I don't think we should add that syntax until I do get it through the
committee, just in case they change something.
--
Vik Fearing
On 1/1/23 20:21, Tom Lane wrote:
Vik Fearing writes:
Hmm. Somehow the .out test files were not included.
Fixed with attached.
Somehow you'd managed to duplicate some of the other changes,
so the cfbot still didn't like that :-(
Anyway, pushed with cosmetic changes. Notably, I left out
On 1/1/23 03:10, Vik Fearing wrote:
It has always annoyed me that we can't write '+infinity' for dates and
timestamps and get the OCD satisfaction of making our queries line up
with '-infinity'.
I wrote a fix for that some time ago but apparently never posted it. I
was reminded
, and so
here it is.
--
Vik Fearingcommit 5178a17a3280bc0018194e590d1b9fb3afbe3b65
Author: Vik Fearing
Date: Tue Jun 7 00:22:21 2022 +0200
allow +infinity for dates
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index fdffba4442..863ab84442 100644
--- a/doc/src/sgml
but it
appears I never posted it. I will post that in a new thread so as not
to confuse the bots.
--
Vik Fearing
On 12/23/22 00:47, David Rowley wrote:
On Wed, 26 Oct 2022 at 14:38, David Rowley wrote:
I've now pushed the final result. Thank you to everyone who provided
input on this.
This is a very good improvement. Thank you for working on it.
--
Vik Fearing
, what does the specification tells about seeds, normal and random
functions?
Nothing at all.
--
Vik Fearing
for every type like we do for arrays on the off-chance you would want to
put it in a PERIOD for example.
For those who know the code much better than I do, what would be a
plausible way forward to support these containers?
--
Vik Fearing
, but what is the point of the file identifiers?
--
Vik Fearing
I don't know what my opinion is on that.
--
Vik Fearing
On 12/18/22 15:24, Tom Lane wrote:
Vik Fearing writes:
Are there any objections to me writing a patch to add SQL Standard
regular expression functions even though they call for XQuery and we
would use our own language?
Yes. If we provide spec-defined syntax it should have spec-defined
would use our own language?
--
Vik Fearing
rspecified.
That is a good point
I also wonder whether we'd accept any ORDER BY whatsoever, or try
to require one that produces a sufficiently-unique input ordering.
I would accept anything. agg(x order by y) is a common thing.
--
Vik Fearing
On 12/13/22 14:25, Isaac Morland wrote:
On Tue, 13 Dec 2022 at 07:50, Vik Fearing wrote:
I am proposing something like pg_aggregate.aggordering which would be an
enum of behaviors such as f=Forbidden, a=Allowed, r=Required. Currently
all aggregates would have 'a' but I am thinking that a lot
On 12/13/22 13:55, Magnus Hagander wrote:
On Tue, Dec 13, 2022 at 1:51 PM Vik Fearing wrote:
The standard only defines an ORDER BY clause inside of an aggregate for
ARRAY_AGG(). As an extension to the standard, we allow it for all
aggregates, which is very convenient for non-standard things
, but this is the approach I am aiming for.
Thoughts?
--
Vik Fearing
On 12/8/22 06:48, David G. Johnston wrote:
On Wed, Dec 7, 2022 at 10:00 PM Vik Fearing wrote:
On 12/7/22 04:22, David G. Johnston wrote:
On Mon, Dec 5, 2022 at 10:40 PM Vik Fearing
wrote:
On 12/6/22 05:57, David G. Johnston wrote:
On Mon, Dec 5, 2022 at 9:48 PM Vik Fearing
wrote
On 12/7/22 04:22, David G. Johnston wrote:
On Mon, Dec 5, 2022 at 10:40 PM Vik Fearing wrote:
On 12/6/22 05:57, David G. Johnston wrote:
On Mon, Dec 5, 2022 at 9:48 PM Vik Fearing
wrote:
I can imagine an optimization that would remove an ORDER BY clause
because it isn't needed for any
On 12/6/22 05:57, David G. Johnston wrote:
On Mon, Dec 5, 2022 at 9:48 PM Vik Fearing wrote:
I can imagine an optimization that would remove an ORDER BY clause
because it isn't needed for any other aggregate.
I'm referring to the query:
select any_value(v order by v) from (values (2),(1
On 12/6/22 05:22, David G. Johnston wrote:
On Mon, Dec 5, 2022 at 8:46 PM Vik Fearing wrote:
On 12/5/22 18:56, David G. Johnston wrote:
Also, maybe we should have any_value do something like compute a 50/50
chance that any new value seen replaces the existing chosen value,
instead
for it? I will happily write a patch for it, and also
submit it to the SQL Committee for inclusion in the standard. I need to
justify why it's a good idea, though, and we would need to consider what
to do with nulls now that there is .
--
Vik Fearing
that used reservoir
sampling to get an evenly distributed value from the inputs. Something
like that seems to be what you are looking for here. I don't see the
use case for adding it to core, though.
The use case for ANY_VALUE is compliance with the standard.
--
Vik Fearing
On 12/5/22 15:57, Vik Fearing wrote:
The SQL:2023 Standard defines a new aggregate named ANY_VALUE. It
returns an implementation-dependent (i.e. non-deterministic) value from
the rows in its group.
PFA an implementation of this aggregate.
Here is v2 of this patch. I had forgotten
The SQL:2023 Standard defines a new aggregate named ANY_VALUE. It
returns an implementation-dependent (i.e. non-deterministic) value from
the rows in its group.
PFA an implementation of this aggregate.
Ideally, the transition function would stop being called after the first
non-null was
]
::=
ERROR
| NULL
| DEFAULT
Once/If I get that in, I will be pushing to get that syntax in postgres
as well.
--
Vik Fearing
DISTINCT column, otherwise, you just destroy the
tuplesort and rinse and repeat for the next aggregate.
>
This looks like way to go that would ensure main use case of portability
from Oracle.
The goal should not be portability from Oracle, but adherence to the
standard.
--
Vik Fearing
On 11/29/22 17:29, Laurenz Albe wrote:
On Tue, 2022-11-29 at 13:58 +0100, Vik Fearing wrote:
I disagree. A user does not need to know that a table is partitionned,
and if the user wants a unique constraint on the table then making them
type an extra word to get it is just annoying.
Hmm
partition keys, which is good.
If we were to automatically turn that into a global unique index, user may be
using the feature without knowing and experiencing some performance impacts (to
account for extra uniqueness check in all partitions).
I disagree. A user does not need to know that a table is partitionned,
and if the user wants a unique constraint on the table then making them
type an extra word to get it is just annoying.
--
Vik Fearing
amname
-> Seq Scan on pg_catalog.pg_am
Output: amname
(9 rows)
--
Vik Fearing
o, the specification for ROW_NUMBER() is:
f) ROW_NUMBER() OVER WNS is equivalent to the :
COUNT (*) OVER (WNS1 ROWS UNBOUNDED PRECEDING)
So I don't think we need to test for anything at all and can
indiscriminately add or replace the frame with ROWS UNBOUNDED PRECEDING.
--
Vik Fearing
course.
I haven't tested the patch yet, just read it.
Is there any reason to use BY DEFAULT over ALWAYS? I tend to prefer the
latter.
--
Vik Fearing
by the committer.
Marked as Ready for Committer. Thanks for the patch!
--
Vik Fearing
not differ from the third one and from
other examples in docs.
I agree with both of these patches (especially the semicolon part which
is not subjective).
--
Vik Fearing
for (B).
--
Vik Fearing
, and "\dt *.*" showing all.
Hm, I could get on board with that -- any other opinions?
+1
--
Vik Fearing
stated that the SQL spec seemed to imply that you had to track all those
things.
The spec does not allow schema changes at all on a a system versioned
table, except to change the system versioning itself.
--
Vik Fearing
Surafel's attempt because it was
confusing the period with SYSTEM VERSIONING. Versioning needs the
period but the inverse is not true.
--
Vik Fearing
suitable reserved keyword?
I don't particularly like this whole idea anyway, but if we're going to
have it, I would suggest
JOIN ... USING KEY ...
since USING currently requires a parenthesized list, that shouldn't
create any ambiguity.
> How about JOIN WITH?
WITH is severely overloaded already.
--
Vik Fearing
ould just be rejected, unfortunately.
The design decisions are just too flawed, and it conflates system_time
periods with system versioning which is very wrong.
--
Vik Fearing
).
The patch looks good to me, too.
+1
--
Vik Fearing
required(and
> it should not error-out by Postgres).
What could possibly be the use case for this?
> Thoughts?
I don't like it.
--
Vik Fearing
On 11/2/21 11:14 PM, Vik Fearing wrote:
> This would be nice, but there is nothing to hang our hat on:
>
> GRANT CHECKPOINT TO username;
Thinking about this more, why don't we just add CHECKPOINT and
NOCHECKPOINT attributes to roles?
ALTER ROLE username WITH CHECKPOINT;
--
Vik Fearing
GRANT VACUUM, ANALYZE ON TABLE foo TO bar;
That doesn't fix the CHECKPOINT issue, but surely vacuum and analyze can
be done that way. I would much prefer that over new predefined roles.
This would be nice, but there is nothing to hang our hat on:
GRANT CHECKPOINT TO username;
--
Vik Fearing
)?
If we're going to do something like that, we should convert it from a
boolean to an enum.
log_checkpoints = wal
(I'm being very careful not to slip on that slope.)
--
Vik Fearing
of an interest to allow that.
Allowing no-column tables removed the need to handle a bunch of corner
cases. Useful for users or not, the precedent is set.
--
Vik Fearing
On 10/17/21 11:01 PM, Gilles Darold wrote:
>
> - Add a check into SET UNEXPANDED code to verify that there is at
> least one column expanded.
What is the point of this? Postgres allows column-less tables.
Both of these statements are valid:
- CREATE TABLE nada ();
- SELECT
t to see ALL columns.
I disagree strongly with this. It is really annoying when working
interactively with psql on a table that has a PostGIS geometry column,
or any other large blobby type column.
I have not looked at the patch, but +1 for the feature.
--
Vik Fearing
On 10/13/21 2:06 AM, Bossart, Nathan wrote:
> On 10/11/21, 11:03 AM, "Vik Fearing" wrote:
>> On 10/11/21 5:25 PM, PG Bug reporting form wrote:
>>>
>>> User 'musttu' on IRC reported the following bug: After running "ALTER INDEX
>>> some_idx
Better to be clear that such nonsense isn't
> intended to be accepted and clean that up. I do think it'd be good to
> accept the current database name there as that's reasonable.
I am going to throw my hat in with Robert and Stephen, too. At least
for 15 if we don't want to change this behavior in back branches.
--
Vik Fearing
On 10/7/21 4:21 PM, Stephen Frost wrote:
> Greetings,
>
> * Vik Fearing (v...@postgresfriends.org) wrote:
>> On 10/6/21 8:48 PM, Stephen Frost wrote:
>>> Consider that with what you're proposing, a user could execute the
>>> following series of entirely SQL-s
way I read the spec, r2 would be destroyed along with its objects.
12.7 GR 30.b.i says to destroy all abandoned role authorization
descriptors, and r2 matches that according to my reading of 12.7 GR 7.
--
Vik Fearing
I don't have the skills to work on either side of this, but I would like
to voice my support in favor of having this feature and I would be happy
to help test it on a user level (as opposed to reviewing code).
--
Vik Fearing
or at least should.
On the other hand, if there is no optimization or other meaningful
difference between SCROLL and NO SCROLL, then we can just document it as
a no-op that is only provided for standard syntax compliance.
--
Vik Fearing
On 9/8/21 3:14 PM, Tom Lane wrote:
> Vik Fearing writes:
>
>> Is there any hope of adding the optional underscores? I see a potential
>> problem there as SELECT 1_a; is currently parsed as SELECT 1 AS _a; when
>> it should be parsed as SELECT 1_ AS a; or perhaps even as
problem there as SELECT 1_a; is currently parsed as SELECT 1 AS _a; when
it should be parsed as SELECT 1_ AS a; or perhaps even as an error since
0x1_a would be a valid number with no alias.
(The standard does not allow identifiers to begin with _ but we do...)
--
Vik Fearing
CREATE TABLE likeamlike(
LIKE likeam1 INCLUDING ACCESS METHOD,
LIKE likeam2 INCLUDING ACCESS METHOD
);
At the very least, the documentation should say that the last one wins.
--
Vik Fearing
> Let me know your thoughts; I personally find this to be useful, and would be
> a nicer way for some
> configs to be displayed in the postgresql.conf file.
As discussed on IRC, I am in favor of this improvement. (I have not yet
looked at the patch.)
--
Vik Fearing
On 4/15/21 12:18 AM, Mark Dilger wrote:
>
>
>> On Apr 14, 2021, at 2:47 PM, Vik Fearing wrote:
>>
>> On 4/14/21 7:36 PM, Tom Lane wrote:
>>> Mark Dilger writes:
>>>>> On Apr 13, 2021, at 3:26 PM, Tom Lane wrote:
>>>>> How
ough to break feature freeze for,
> but I'm +1 for investigating it for v15.
Just like we have a pseudo "$user" schema, could we have a pseudo
"$extension" catalog? That should avoid changing grammar rules too much.
CREATE TABLE unaccented_words (
word "$extension".citext.citext,
CHECK (word = "$extension".unaccent.unaccent(word)
);
--
Vik Fearing
and modern joins, and you
> are inventing a third syntax.
I'm with you on this: let's do it the Standard way, or not do it at all.
--
Vik Fearing
On 3/29/21 7:55 PM, Joel Jacobson wrote:
> On Mon, Mar 29, 2021, at 16:17, Vik Fearing wrote:
>> CREATE TABLE order_details (
>> "order" REF(orders),
>> product REF(products),
>> quantity integer,
>> PRIMARY KEY ("order", product
products (
REF IS product_id SYSTEM GENERATED
);
CREATE TABLE order_details (
"order" REF(orders),
product REF(products),
quantity integer,
PRIMARY KEY ("order", product)
);
And the query would be:
SELECT DISTINCT order_details."order"->customer->company_name
FROM order_details
WHERE order_details.product->product_name = 'Chocolade';
Postgres already supports most of that, but not all of it.
--
Vik Fearing
On 3/28/21 1:26 PM, Joel Jacobson wrote:
> On Sun, Mar 28, 2021, at 12:25, Vik Fearing wrote:
>> On 3/27/21 9:27 PM, Joel Jacobson wrote:
>>> Imagine if we could simply write the SQL query like this:
>>>
>>> SELECT DISTINCT od.order_id.customer_id.compa
s August 2022 (it started in September 2019).
If that timeline holds and ambitious people work on it (I already know
one who is; not me), I would expect this to be in PostgreSQL 16 or 17.
The earliest your proposal could get in is 15, so it's not that much of
a wait.
--
Vik Fearing
ished, I would like to see
this integrated into the tree, perhaps even directly into psql itself
(unless the user chooses a different pager). It is that useful.
Thank you, Pavel, for this work.
--
Vik Fearing
oticed
> this, not the new fancy ones.
+1
I'm glad the buildfarm is so diverse.
--
Vik Fearing
until I finish my review of
the system versioning patch.
> perhaps it would be better to close it as Returned with
> Feedback for now and reopen it when you have a new patch?
If that is preferred over moving it to PG15, then no objection. As long
as people don't think I've abandoned it.
--
Vik Fearing
On 3/17/21 3:48 PM, Tom Lane wrote:
> Also, the SQL spec says in so many words
> that the SQL-defined datetime types follow the Gregorian calendar.
We already don't follow the SQL spec for timestamps (and I, for one,
think we are better for it) so I don't think we should worry about that.
-
d.
>
> So, my question is: what do you think about such a feature? is it worth it?
Yes, it is absolutely worth it to be able to extract just the functions
from a database. I have wanted this several times.
--
Vik Fearing
On 3/17/21 9:11 AM, Michael Paquier wrote:
> On Wed, Mar 17, 2021 at 08:31:16AM +0100, Vik Fearing wrote:
>> When table oids were removed by commit 578b229718e, the function
>> CatalogTupleInsert() was modified to return void but its comment was
>> left intact. Here is a
When table oids were removed by commit 578b229718e, the function
CatalogTupleInsert() was modified to return void but its comment was
left intact. Here is a trivial patch to fix that.
--
Vik Fearing
diff --git a/src/backend/catalog/indexing.c b/src/backend/catalog/indexing.c
index 284ceaa6b9
in that? I left it
alone for now.
I also snuck in something that all of us overlooked which is outputting
the DISTINCT in ruleutils.c. I didn't add a test for it but that would
have been an unfortunate bug.
New patch attached, rebased on 15639d5e8f.
--
Vik Fearing
>From d83e2237578f774aaf3
ag to get StartTime/EndTime column name,
>>> thought?
>>>
>>>
> For me your option is better. i will change to it in my next
> patch if no objection
I have plenty of objection. I'm sorry that I am taking so long with my
review. I am still working on it and it is coming soon, I promise.
--
Vik Fearing
On 3/7/21 11:37 AM, Pavel Stehule wrote:
> ne 7. 3. 2021 v 11:28 odesílatel Vik Fearing
> napsal:
>
>> On 3/7/21 11:24 AM, Pavel Stehule wrote:
>>>>
>>>> And so you are now mandating an ORDER BY on every query and in every
>>>> aggregate and/o
r median (percentile_cont(0.5)) already requires an order
by clause. You are now requiring one on array_agg().
--
Vik Fearing
On 3/7/21 11:05 AM, Pavel Stehule wrote:
> ne 7. 3. 2021 v 11:02 odesílatel Vik Fearing
> napsal:
>
>> On 3/7/21 10:53 AM, Pavel Stehule wrote:
>>> ne 7. 3. 2021 v 10:36 odesílatel Vik Fearing
>>> napsal:
>>>
>>>> On 3/6/21 9:06 PM, Dav
On 3/7/21 10:53 AM, Pavel Stehule wrote:
> ne 7. 3. 2021 v 10:36 odesílatel Vik Fearing
> napsal:
>
>> On 3/6/21 9:06 PM, David G. Johnston wrote:
>>> On Saturday, March 6, 2021, David Fetter wrote:
>>>
>>>>
>>>>>> SELECT B
>>
>
> Numerous existing aggregate functions have this behavior. Making those
> error isn’t an option. So is making this a special case something we want
> to do (and also maybe make doing so the rule going forward)?
Aside from the fact that bit_xor() does not need this, I am opposed to
it in general. It is not our job to make people write correct queries.
--
Vik Fearing
On 3/6/21 9:00 PM, David Fetter wrote:
> On Sat, Mar 06, 2021 at 08:57:46PM +0100, Vik Fearing wrote:
>> On 3/6/21 8:55 PM, David Fetter wrote:
>>> On Wed, Mar 03, 2021 at 03:30:15PM +0100, Peter Eisentraut wrote:
>>>> On 10.02.21 06:42, Kyotaro Horiguchi wrot
s there some way to refuse to execute
> it if it doesn't contain an unambiguous ORDER BY, as illustrated
> below?
>
> SELECT BIT_XOR(b ORDER BY a, c).../* works */
> SELECT BIT_XOR(b) OVER (ORDER BY a, c)... /* works */
> SELECT BIT_XOR(b) FROM... /* errors out */
Why would such an error be necessary, or even desirable?
--
Vik Fearing
e semantics.
Thank you.
> Looks good otherwise, so pushed.
Thanks!
--
Vik Fearing
On 3/3/21 6:35 PM, Peter Eisentraut wrote:
> On 22.02.21 08:00, Vik Fearing wrote:
>> On 2/22/21 3:24 AM, Andres Freund wrote:
>>> Imagine trying to run regular tests of HEAD, where the tests require a
>>> large database to be loaded. Re-loading the d
bumping to 'Ready for Committer' unless objections.
In that case, here is another patch that fixes a typo in the docs
mentioned privately to me by Erik. The typo (and a gratuitous rebase)
is the only change to what you just reviewed.
--
Vik Fearing
>From e8c0042267abc2dedea8ecca2c6bfde22227118d Mon Se
On 3/2/21 1:02 AM, Dian M Fay wrote:
> On Mon Mar 1, 2021 at 6:53 PM EST, Vik Fearing wrote:
>>> This basically does what it says, and the code looks good. The
>>> documentation is out of alphabetical order (trim_array should appear
>>> under cardinality rather
ing on Author
I put it back to Needs Review without a new patch because I don't know
what I would change.
--
Vik Fearing
On 2/22/21 1:28 PM, Peter Eisentraut wrote:
> On 22.02.21 11:05, Vik Fearing wrote:
>> This looks good to me, except that you forgot to add the feature stamp.
>> Attached is a small diff to apply on top of your patch to fix that.
>
> The feature code is from SQL:20
L:202x draft.
Yay!
> Here is a patch for it.
This looks good to me, except that you forgot to add the feature stamp.
Attached is a small diff to apply on top of your patch to fix that.
--
Vik Fearing
diff --git a/src/backend/catalog/sql_features.txt b/src/backend/catalog/sql_features.txt
index a2
ke to re-use a "template" data directory with the
> data loaded if possible (i.e. no catversion / WAL / ... version bumps),
> and a pg_upgrade otherwise.
This is exactly what I am doing.
--
Vik Fearing
On 2/22/21 12:48 AM, Andres Freund wrote:
> Hi,
>
> On 2021-02-22 00:15:20 +0100, Vik Fearing wrote:
>> I do some very regular testing on HEAD and my scripts need to know if
>> the catalog version has changed to determine if it needs to pg_restore
>> or if a basebacku
nd I would like for it to appear there.
Please consider.
--
Vik Fearing
>From a06fd975ef14930bbef2dac3597272289d6b10eb Mon Sep 17 00:00:00 2001
From: Vik Fearing
Date: Fri, 13 Nov 2020 11:55:58 +0100
Subject: [PATCH 1/2] Add catalog version to pg_config
---
doc/src/sgml/ref/pg_config
On 2/21/21 3:06 PM, e...@xs4all.nl wrote:
>> On 2021.02.21. 13:52 Vik Fearing wrote:
>>
>> Attached is a patch to implement this for PostgreSQL.
>> []
>
> The changed line that gets stuffed into sql_features is missing a terminal
> value (to fill the 'comment
)
expands to the sets:
(a,b,c), (a,b), (a,b), (a,c), (a), (a), (a,c), (a), ()
but:
GROUP BY DISTINCT ROLLUP (a,b), ROLLUP (a,c)
expands to just the sets:
(a,b,c), (a,b), (a,c), (a), ()
Attached is a patch to implement this for PostgreSQL.
--
Vik Fearing
>F
On 2/17/21 1:25 AM, Vik Fearing wrote:
> I've made a bit of a mess out of this, but I partly blame the standard
> which is very unclear. It actually describes trimming the right n
> elements instead of the left n like I've done here. I'll be back later
> with a better patch that do
On 2/16/21 11:38 PM, Vik Fearing wrote:
> On 2/16/21 7:32 PM, Isaac Morland wrote:
>> On Tue, 16 Feb 2021 at 12:54, Vik Fearing wrote:
>>
>>> The SQL standard defines a function called TRIM_ARRAY that surprisingly
>>> has syntax that looks like a function!
On 2/16/21 7:32 PM, Isaac Morland wrote:
> On Tue, 16 Feb 2021 at 12:54, Vik Fearing wrote:
>
>> The SQL standard defines a function called TRIM_ARRAY that surprisingly
>> has syntax that looks like a function! So I implemented it using a thin
>> wrapper aroun
inlining.
Patch attached.
--
Vik Fearing
>From 6429316ab6060a16889b7c188ca577e17a5c7e4c Mon Sep 17 00:00:00 2001
From: Vik Fearing
Date: Tue, 16 Feb 2021 18:38:24 +0100
Subject: [PATCH] implement trim_array
---
doc/src/sgml/func.sgml | 19 +++
src/include/cata
On 1/26/21 6:34 PM, Vik Fearing wrote:
> On 1/26/21 6:20 PM, Laurenz Albe wrote:
>> After thinking some more about it, I think that COMMIT AND CHAIN would have
>> to change behavior: if COMMIT throws an error (because the transaction was
>> aborted), no new transact
hould become ROLLBACK AND NO CHAIN.
--
Vik Fearing
On 1/26/21 1:16 PM, Simon Riggs wrote:
> On Tue, Jan 26, 2021 at 11:33 AM Vik Fearing wrote:
>>
>> On 1/11/21 3:02 PM, Simon Riggs wrote:
>>> * UPDATE foo SET start_timestamp = DEFAULT should fail but currently doesn't
>>
>> I'm still in the weeds of
On 1/11/21 3:02 PM, Simon Riggs wrote:
> * UPDATE foo SET start_timestamp = DEFAULT should fail but currently doesn't
I'm still in the weeds of reviewing this patch, but why should this
fail? It should not fail.
--
Vik Fearing
101 - 200 of 425 matches
Mail list logo
