This should resolve https://pagure.io/koji/issue/1980
It requires a postgresql 9.0 feature to simplify the filter aggregate join.
how about using array_agg instead of string_agg?
array_agg
string_agg
To be honest, I had no idea that existed. I'll see about switching over to that.
It looks like the output format of array_agg is a bit weird to me.... {"",192a7d7d} doesn't seem to have a simple way to convert into python data types.
{"",192a7d7d}
ah, it will be translated to ["", "192a7d7d"]as a python list by psycopg2
["", "192a7d7d"]
you could refer to how is it used in listUsers API
listUsers
rebased onto 88a525441bfb5ae5df821cd896fccaa6b560047f
Perhaps something like my latest push?
yes :thumbsup:
similar to #1999 - I would rather like to see it driven by option. get_rpm is used in many places and most of them doesn't need this information.
get_rpm
Or more generally, usecase is only CLI here, or do you need it somewhere via API? Why not to use queryRPMSigs with mutlicall instead in handle_buildinfo?
queryRPMSigs
handle_buildinfo
My initial use case is for the CLI and to eventually expose it to admin users in the web ui.
admin
@jcpunk Would #2016 be ok?
pretty please pagure-ci rebuild
That looks viable to me.
Ok, closing this as obsoleted by #2016
Pull-Request has been closed by tkopecek
This should resolve https://pagure.io/koji/issue/1980
It requires a postgresql 9.0 feature to simplify the filter aggregate join.