stions wrt to the
actual escape method to use.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
5-10% vs fairly recent HEAD (same as my
last pgbench runs).
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e-friendly locations.
FWIW, I've tested HEAD vs patch on a 2-cpu low end NetBSD 7.0 i386 machine.
HEAD: 1890/1935/1889 tps
kqueue: 1905/1957/1932 tps
no weird surprises, and basically no differences either.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com
Hi Tom,
On 27/05/2014 15:52, Tom Lane wrote:
> Matteo Beccati writes:
>> On 27/05/2014 03:07, Tom Lane wrote:
>>> I do not have a machine on which to try --with-bsd-uuid, so it's
>>> possible I broke that portion of Matteo's patch. Would someone try
>&
ot; was raising a warning about the
condition being always true on BSD. I guess it's safe to hardcode 13 as
the argument is ignored anyway with ossp, so I've fixed that.
I've also fixed v1mc generation on "linux" to match the OSSP and BSD
variants and added a regression te
On 26/05/2014 19:31, Andres Freund wrote:
> On 2014-05-26 13:25:49 -0400, Tom Lane wrote:
>> Matteo Beccati writes:
>>> I'm attaching v2 of the patch. Here's a list of changes from v1:
>>
>>> * Restored --with-ossp-uuid. Configure tries ossp support
Hi Tom,
thanks for the feedback.
On 25/05/2014 21:10, Tom Lane wrote:
> Matteo Beccati writes:
>> here's the latest version of my uuid changes patch, according to
>> proposal (2) from Tom in the thread about OSSP-UUID[1].
>
> Hmm ... this is not actually what
On 23/05/2014 10:05, Matteo Beccati wrote:
> You can find the code here:
> https://github.com/mbeccati/uuid # NetBSD variant
> https://github.com/mbeccati/uuid/tree/linux # Ubuntu variant
>
> For now, I've forked just RhodiumToad's uuid-freebsd extension, but I've
&g
On 22/05/2014 21:55, Matteo Beccati wrote:
> On 22/05/2014 17:07, Tom Lane wrote:
>> Well, *I* don't want to do that work. I was hoping to find a volunteer,
>> but the silence has been notable. I think deprecation is the next step.
>
> This sounds an easy enough task
successfully compiled the extension on a NetBSD box using a
slightly modified version of Palle's patch. I have a few doubts though:
- should we keep the extension name? If not, what would be the plan?
- the patch also uses BSD's own md5 and sha1 implementations: for md5 I
should be ab
beccati.org in the
"message-id" link:
http://archives.postgresql.org/message-id/1320343602-sup-2...@alvh.no-ip.org
->
http://archives.beccati.org/message-id/1320343602-sup-2...@alvh.no-ip.org
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 17/01/2012 18:10, Matteo Beccati wrote:
> On 17/01/2012 17:50, Alvaro Herrera wrote:
>>
>> Excerpts from Matteo Beccati's message of mar ene 17 12:33:27 -0300 2012:
>>> My proof of concept archive for the hackers ML site is still online, in
>>> case anyone
Now that we've migrated the website, it's time to get back to our
> conversations about migrating archives to your stuff too. How confident
> with Django are you?
I've never wrote a line of Python in my life, so someone else should
work on porting the web part, I'm afr
the output
matches the result of my script.
The only little thing I've noticed is a missing ending ")" in the --help
message.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
pretty nice win.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
link leads to 404 Not Found.
Thanks for the private email to point this thread out. I've been overly
busy lately and missed it.
I'll try to debug what happens with your message formatting as soon as I
can find some time.
Cheers
--
Matteo Beccati
Development & Consulting
On 01/02/2010 17:28, Tom Lane wrote:
Matteo Beccati writes:
My main concern is that we'd need to overcomplicate the thread detection
algorithm so that it better deals with delayed messages: as it currently
works, the replies to a missing message get linked to the
"grand-parent"
On 01/02/2010 15:03, Magnus Hagander wrote:
2010/2/1 Matteo Beccati:
My main concern is that we'd need to overcomplicate the thread detection algorithm so
that it better deals with delayed messages: as it currently works, the replies to a
missing message get linked to the "gr
missing message get linked to the
"grand-parent". Injecting the missing message afterwards will put it at
the same level as its replies. If it happens only once in a while I
guess we can live with it, but definitely not if it happens tens of
times a day.
Cheers
--
Matteo Beccati
D
On 01/02/2010 03:27, Alvaro Herrera wrote:
Matteo Beccati wrote:
Incidentally, I've just found out that the mailing lists are
dropping some messages. According to my qmail logs the AOX account
never received Joe's message yesterday, nor quite a few others:
M156252, M156259, M15626
On 31/01/2010 13:45, Magnus Hagander wrote:
On Sat, Jan 30, 2010 at 22:43, Matteo Beccati wrote:
On 30/01/2010 17:54, Alvaro Herrera wrote:
* While I don't personally care, some are going to insist that the site
works with Javascript disabled. I didn't try but from your desc
On 30/01/2010 22:18, Joe Conway wrote:
On 01/30/2010 01:14 PM, Dimitri Fontaine wrote:
Matteo Beccati writes:
I've been following the various suggestions. Please take a look at the
updated archives proof of concept:
http://archives.beccati.org/
I like the features a lot, and the
On 30/01/2010 17:54, Alvaro Herrera wrote:
Matteo Beccati wrote:
Il 19/01/2010 09:44, Magnus Hagander ha scritto:
As long as the templating is separated from the code, it doesn't
matter if it's a dedicated templating engine or PHP. The point being,
focus on the contents and interfac
her one (/list/-mm/msg*.php) is implemented, but I just
realized that it has problems dealing with the old archive weirdness
(2009-12 shows also some messages dated aug 2009 nov 2009 or jan 2010
for -hackers).
That said, there are still a few visual improvements to be done, but
overall I'm pr
I've seen it a few days ago with 8.5alpha3 on NetBSD when I left the
backend running for a few days. Backend was completely inactive but the
massage was repeated 3-4 times. Googling didn't help and I didnt' know
how to replicate it.
Cheers
--
Matteo Beccati
Development &a
Il 18/01/2010 18:42, Magnus Hagander ha scritto:
On Mon, Jan 18, 2010 at 18:31, Matteo Beccati wrote:
Il 18/01/2010 15:55, Magnus Hagander ha scritto:
If it wasn't for the fact that we're knee deep in two other major
projects for the infrastructure team right now, I'd b
ss of an
index scan. But I'm happy to examine other alternatives too.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
erent from what is going to be used on
production (symfony/php vs django/python).
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Il 16/01/2010 14:21, Matteo Beccati ha scritto:
Il 16/01/2010 11:48, Dimitri Fontaine ha scritto:
Matteo Beccati writes:
Anyway, I've made further changes and I would say that at this point
the PoC
is feature complete. There surely are still some rough edges and a few
things to clean up
Il 16/01/2010 11:48, Dimitri Fontaine ha scritto:
Matteo Beccati writes:
Anyway, I've made further changes and I would say that at this point the PoC
is feature complete. There surely are still some rough edges and a few
things to clean up, but I'd like to get your feedback once ag
Hi everyone,
Il 14/01/2010 19:36, David Fetter ha scritto:
On Thu, Jan 14, 2010 at 03:08:22PM +0100, Matteo Beccati wrote:
Il 14/01/2010 14:39, Dimitri Fontaine ha scritto:
Matteo Beccati writes:>
Any improvements to sorting are welcome :)
...
ARRAY[uid]
...
Thanks Da
Il 14/01/2010 15:47, Dimitri Fontaine ha scritto:
Matteo Beccati writes:
WITH RECURSIVE t (mailbox, uid, date, subject, sender, has_attachments,
parent_uid, idx, depth) AS (
SELECT mailbox, uid, date, subject, sender, has_attachments, parent_uid,
uid::text, 1
FROM arc_messages
WHERE
Il 14/01/2010 14:46, Dave Page ha scritto:
On Thu, Jan 14, 2010 at 7:09 PM, Dimitri Fontaine
wrote:
Matteo Beccati writes:
I've extended AOX with a trigger that takes care of filling a separate table
that's used to display the index pages. The new table also stores threading
i
Il 14/01/2010 14:39, Dimitri Fontaine ha scritto:
Matteo Beccati writes:
I've extended AOX with a trigger that takes care of filling a separate table
that's used to display the index pages. The new table also stores threading
information (standard headers + Exchange headers su
Il 14/01/2010 08:22, Matteo Beccati ha scritto:
Hi,
3) A nice set of SQL queries to return message, parts, threads,
folders based on $criteria (search, id, folder, etc)
I guess Matteo's working on that…
Right, but this is where I want to see the AOX schema "imporove"... In
w
)
I'm looking into it. The link I've previously sent will most likely
return a 500 error for the time being.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Il 12/01/2010 21:04, Magnus Hagander ha scritto:
On Tue, Jan 12, 2010 at 20:56, Matteo Beccati wrote:
Il 12/01/2010 10:30, Magnus Hagander ha scritto:
The problem is usually with strange looking emails with 15 different
MIME types. If we can figure out the proper way to render that, the
rest
a poc, and it was less than 30 minutes of
hacking. Can't seem to find the script ATM though, but you get the
idea.
Let's not focus on that part, we can easily solve that.
Agreed. That's the part that worries me less.
Cheers
--
Matteo Beccati
Development & Consult
With all that said, I can't promise anything as it all depends on how
much spare time I have, but I can proceed with the evaluation if you
think it's useful. I have a feeling that AOX is not truly the right tool
for the job, but we might be able to customise it to suit our needs. A
a (a int);
CREATE TABLE
test=# ANALYZE a;
ANALYZE
test=# EXPLAIN SELECT * from a;
QUERY PLAN
-
Seq Scan on a (cost=0.00..14.80 rows=2400 width=4)
(1 row)
That said, 2400^3 (cross join of 3 tables) == 13824000000
C
made trying to learn how to use
symfony this afternoon. It's not feature complete, nor probably very
scalable, but at least it features attachment download ;)
http://archives.beccati.org/pgsql-hackers/message/37
Cheers
--
Matteo Beccati
Development & Consulting - http://www.becca
Il 11/01/2010 12:58, Dave Page ha scritto:
On Mon, Jan 11, 2010 at 5:23 PM, Matteo Beccati wrote:
I recall having tried AOX a long time ago but I can't remember the reason
why I was not satisfied. I guess I can give another try by setting up a test
ML archive.
I tried it too, bef
Tuesday or so (at this time of
the day, that is, because I have to take care of the other daughter).
I'll be probably away for (at least) a week when she does; and I'll
probably have somewhat of a shortage of spare time after that.
BTW, congrats Alvaro!
Cheers
--
Matteo
g the
process[1].
This means that most of the PHP applications should work fine with 8.5
when running recent enough PHP versions. The few that are using both PDO
and bytea fields will require a switch to 5.3 (or 5.2.13 whenever it
comes out).
[1] http://bugs.php.net/50575
Cheers
--
M
Il 25/12/2009 18:54, Tom Lane ha scritto:
Matteo Beccati writes:
However, before taking a look at the actual code and understanding its
behaviour, I tried using "SET bytea_output = 'escape'" and I was
expecting PQescapeByteaConn to honour it.
Why? PQescapeByteaConn
'escape'" and I was
expecting PQescapeByteaConn to honour it. Not sure if changing the
current behaviour is at all possible, desirable and really worth it, but
I'm going to hold the patches to the php test suite until I get some
feedback here.
Thoughts?
Cheers
--
Matteo Beccati
26 rows=3139126
width=24)
-> Seq Scan on part_e foo (cost=0.00..60552.85 rows=3130785
width=24)
-> Seq Scan on part_f foo (cost=0.00..60484.31 rows=3127231
width=24)
Cheers
--
Matteo Beccati
http://www.openx.org/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
ndby to know if they understand how it works now and if it's
what they intended when they set it up.
My fault not RTFM well enough, but I was surprised finding out that -t
is working like that.
+1 for me to switch -t to the new behaviour.
Cheers
--
Matteo Beccati
OpenX - http://www.openx.org
ll
table rewrite even though the underlying type definition were exactly
the same (i.e. varchar(64)). I can live with it, but I suppose this fix
might be related to the varlen one.
Cheers
--
Matteo Beccati
OpenX - http://www.openx.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
h the front end
and the deamon use the same pooler to have a common failover process,
previously listening connections could be reused by the web app if the
daemon is restarted and the pooler is not. Does it look plausible?
That said, I don't mind if we go with the previous two-liner fix :)
Cheers
--
Matteo Beccati
OpenX - http://www.openx.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane ha scritto:
Matteo Beccati writes:
Seems like we could/should fix UNLISTEN * to not do anything if it is
known that the current backend never did any LISTENs.
Here's my proposed patch, both for HEAD and 8.3:
This seems a bit overcomplicated. I had in mind something like
ppens.
So, here's the output of some tests I made:
http://www.beccati.com/misc/pgsql/async_unlisten_skip.out
Note: DISCARD doesn't produce any debug output, because the guc
variables are being reset before the Async_UnlistenAll is called.
Cheers
--
Matteo Beccati
OpenX - http://www.open
x UNLISTEN * to not do anything if it is
> known that the current backend never did any LISTENs.
Ok, I'll take sometime tonight to give my patch a try and eventually
submit it.
Cheers
--
Matteo Beccati
OpenX - http://www.openx.org
--
Sent via pgsql-hackers mailing list (pgsql-hacker
bit more
time to it in case it makes sense to you.
Cheers
--
Matteo Beccati
OpenX - http://www.openx.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a was inserted and not yet analyzed again could
cause much more troubles... anyway, I was just curious to get an
"official" anwser ;)
Cheers
--
Matteo Beccati
OpenX - http://www.openx.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
o on
the italian mailing list and I couldn't find a reasonable explanation
for it.
Cheers
--
Matteo Beccati
OpenX - http://www.openx.org
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
samples and up.
Incidentally I hacked up a patch to do this:
Sounds sensible to me, at least much more than a hardcoded magic number
a few people know about...
Cheers
--
Matteo Beccati
Openads - http://www.openads.org
---(end of broadcast
order by and limit for each subquery.
I've tried a few times to write a patch to handle it, but I wasn't able
to do it because of my lack of internals knowledge and spare time.
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(end of bro
l_orderkey?
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
. I'm now restoring a
bigger database to get more reliable results.
I hope Stefan can confirm the improvement on dbt3 too.
Thanks Tom :)
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(end of broadcast)---
TIP 1:
Tom Lane ha scritto:
Matteo Beccati <[EMAIL PROTECTED]> writes:
I cannot see anything bad by using something like that:
if (histogram is large/representative enough)
Well, the question is exactly what is "large enough"? I feel a bit
uncomfortable about applying the idea to
entative enough)
{
recalculate_selectivity_matching_histogram_values()
if (new_selectivity > old_selectivity)
return new_selectivity
else
return old_selectivity
}
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(end of broadcast)---
TIP 6: expla
@> and <@ for future strict comparison operators.
Since the choice of @> and <@ comes from current ltree operators I'd
like to point out that they are non-strict for ltree, and this could add
a little bit of inconsistence.
Best regards
--
Matteo Beccati
http://phpadsnew.
Hi,
Oh, I hadn't noticed that ltree spells it "<@" rather than "@<". I'd be
inclined to stick with the ltree precedent.
This was exactly my implicit proposal :)
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
(or equal).
ltree <@ ltree
- returns TRUE if left argument is a descendant of right argument
(or equal).
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner
nning statistics would
give a better result than using a constant selectivity.
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
Mark,
After all - you wouldn't want somebody to say that PostgreSQL copied
them, because the date was later, would you? :-)
I think it won't be hard to understand what "Copyright (c) 1996-2006"
means ;)
Best regards
--
Matteo Beccati
http://phpadsnew.com
eems to be available since PHP 4.3.0:
http://cvs.php.net/php-src/sapi/embed/php_embed.c
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
be as simple as writing a
new PHP sapi (i.e. sapi/pgsql) which builds the .so without requiring
Apache or other software.
I've also seen there is an experimental embed sapi which could already
be what you need (--enable-embed).
Best regards
--
Matteo Beccati
http://phpadsnew.com
REPLACE INTO t (a, b) VALUES (1, 1);
SELECT * FROM t;
+---+--+--+
| a | b| c|
+---+--+--+
| 1 |1 | NULL |
+---+--+--+
I wanted to point it out this because people are commonly mistaking this.
Best regards
--
Matteo Beccati
http://phpadsnew.co
Tom Lane wrote:
Martijn van Oosterhout writes:
On Fri, Nov 11, 2005 at 11:05:45AM +0100, Matteo Beccati wrote:
It seems that the plan outputted is not the optimized one (available
since 8.1) that is really used when running the plain query.
It may also be that the overhead of calling
RELEASE-p3: times for the same query are 15s vs 63s with
EXPLAIN ANALYZE. Of course I know 8.0 doesn't optimize min/max the same
way 8.1 does.
Hope this helps.
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(end of broadcast)
6462 width=8) (actual time=5.367..2329.015 rows=636462 loops=1)
-> Seq Scan on stats_200511 stats (cost=0.00..1.04 rows=4
width=8) (actual time=0.028..0.041 rows=4 loops=1)
Total runtime: 30692.627 ms
(15 rows)
Time: 30694.357 ms
=
Best regards
--
Matte
nk you all :)
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Hi,
Should I try Alvaro's second patch that you said not going to work?
I'll add that this works for me, that's it prevents invalid alloc
requests to show.
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(e
s meant to be an alternative to it.
Unfortunately it doesn't solve the invalid alloc request issue.
Should I try Alvaro's second patch that you said not going to work?
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
know if you need to test some other patches.
Again, thank you
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-n
g to stress the whole app and with
no errors until now.
Thanks to Matteo for finding the bug!
Thanks to you all for helping out and fixing it :)
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(end of broadcast)---
te
$1 = {nextMXact = 320308, nextOffset = 4235265, lastTruncationPoint =
302016, perBackendXactIds = {0}}
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
Hi Alvaro,
It would be good to see the contents of MultiXactState. I suspect
there's a race condition in the MultiXact code.
Good, but... where do I find the contents of MultiXactState? ;)
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgad
eadlock errors. That subtransaction was actually useless
because I removed the FOR UPDATE clause that was causing the deadlock,
but the alloc error is still there. I'll try to search through the code
to find some other subtransactions.
Best regards
--
Matteo Beccati
I
am unable to produce a test case :(
Lat me know what other I can do to help fixing the bug.
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(end of broadcast)---
TIP 6: explain analyze is your friend
x27;1363827', 'OK 3000')") at postgres.c:1014
#55 0x081dd220 in PostgresMain (argc=4, argv=0x83643d0,
username=0x83643a0 "multilevel") at postgres.c:3168
#56 0x081b01ea in BackendRun (port=0x8361200) at postmaster.c:2855
#57 0x081af7d3 in BackendStartup (p
at postmaster.c:2853
#10 0x081672bd in PostmasterMain (argc=3, argv=0xbfbfed3c) at
postmaster.c:943
#11 0x08131092 in main (argc=3, argv=0xbfbfed3c) at main.c:256
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(end of broadcast)-
quot; line 30 at SQL statement
2
where 4291419108 is a big random number. Please let me know if you need
other details.
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
ld be
wrong, but I didn't get those errors a few days ago (some cvs updates ago).
Best regards
--
Matteo Beccati
http://phpadsnew.com/
http://phppgads.com/
Index: contrib/ltree/ltree.sql.in
===
RCS file: /projects/cvsroot
o it.
Moving it in contrib/ltree would be more difficult to me because it
depends on other functions declared in selfuncs.c
(get_restriction_variable, etc).
Thank you for your feedback
Best regards
--
Matteo Beccati
http://phpadsnew.com/
http://phppgads.com/
---(end of
est the
alternative selectivity function:
CREATE FUNCTION contstatsel(internal, oid, internal, integer) RETURNS
double precision AS 'contstatsel' LANGUAGE internal;
CREATE OPERATOR <<@ (
LEFTARG = ltree,
LEFTARG = ltree,
PROCEDURE = ltree_risparent,
88 matches
Mail list logo
