4 ms·

Cool. If I had to choose I'd wrap the simple py implementation in a PL/Python UDF.

• scrollaway 6y ago
  Why? Implementation-wise, it's far better to have a pure plpgsql function than a Python UDF if you have a choice between the two. A Python UDF would be useful if you need to do more Python stuff in the db in general.
  • Tostino 6y ago
    I mean, why though? I haven't played around much with other languages within Postgres, and mainly stick to pl/pgsql, so real question. Is it performance related? Not requiring another language to be installed?
    • scrollaway 6y ago
      Yes and yes; all other things equal, performance will be a lot worse when using Python. And you'll need Python installed.
      • aidos 6y ago
        Maybe this is the case in general, but a while back we did something that required flipping an array and when we did it with python inside Postgres it was several magnitudes faster.
        • scrollaway 6y ago
          This would make for a super interesting blog post / case study IMO, you should write about it even if it's just to showcase the two algorithms / comparisons.
          • aidos 6y ago
            Sorry, but late back but I’ve just found the code. It’s a bit of a weird case where I needed to reverse arrays inside a big json blob (millions of big json blobs). Trying to explode the structures out and rebuild them was a bit of a no-go. Instead I did a nasty little regex replace on the json string: re.sub('"key": \[([^\\]]+)\]', lambda match: '"key": [' + ', '.join(reversed(match.group(1).split(', '))) + "]", els) There might be a way of doing this in postgres these days (this was 3 or 4 years ago), but I'm not sure. At the time this was the best I could come up with and I was pretty surprised it worked as well as it did. Since then I've always installed the python extension whenever I set up a new postgres, just in case.
            • pyramation 6y ago
              for sure there are all sorts of postgres regex tools... You can likely do everything. The main limitations I found in plpgsql were in base encodings (that were missing), which is why I had to implement base32 from scratch. Besides that, it's pretty much a super powerful language
  • pyramation 6y ago
    agree, this is exactly why the code was written. I had originally tried to use plv8 or others, but as my postgres experience matured and I built testing harnesses, I decided to throw away any non-standard code (plv8, etc). I think often times folks who come to postgres often don't know PL/pgsql (as I also didn't) and prefer to user their language of choice. I truly think if our postgres dev environments were better, we'd find more people writing code this way, so I can empathize with why people would prefer python or JS in the db, but at this stage I can't get myself to use those extensions. FWIW, at one point, AWS didn't support a lot of these (sometimes unsafe) language extensions. So going pure PL/pgsql was the only true path forward. I think now for AWS users, they do support plv8 now, but as you pointed out somewhere in this thread, they are much slower... also I remember plv8 specifically had memory leaks.