| Time |
Nick |
Message |
| 04:39 |
|
degraafk joined #evergreen |
| 06:37 |
|
collum joined #evergreen |
| 09:00 |
|
Dyrcona joined #evergreen |
| 09:25 |
|
mmorgan joined #evergreen |
| 09:44 |
|
mmorgan1 joined #evergreen |
| 09:46 |
|
troy joined #evergreen |
| 09:51 |
|
briank joined #evergreen |
| 09:57 |
|
eby_ joined #evergreen |
| 10:46 |
|
Christineb joined #evergreen |
| 10:51 |
|
troy_ joined #evergreen |
| 10:55 |
|
jihpringle joined #evergreen |
| 10:59 |
Dyrcona |
Heh. I thought I was smarter than the AI when it came to Rust, but I'm not. :) |
| 10:59 |
|
sandbergja joined #evergreen |
| 11:01 |
Dyrcona |
Thought I could do in 1 line what the AI summary did in two, but I lose a temporary value that way and rustc won't compile it.... |
| 11:17 |
|
troy_ joined #evergreen |
| 11:19 |
csharp_ |
looks like ilbot is a dead project: https://github.com/moritz/ilbot |
| 11:19 |
csharp_ |
having trouble finding an alternative, though |
| 11:19 |
|
jweston joined #evergreen |
| 11:19 |
|
jeffdavis joined #evergreen |
| 11:35 |
|
sandbergja joined #evergreen |
| 11:42 |
csharp_ |
might just relay on the ChannelLogger limnoria plugin and expose the logs somehow |
| 11:42 |
csharp_ |
*rely |
| 11:45 |
|
sandbergja|2 joined #evergreen |
| 11:47 |
sandbergja|2 |
Good morning! Do we have an established pattern for code that uses newer postgres functions? I'd like to use regexp_count (introduced in Postgres 15), but keep my code backwards compatible with other supported versions. |
| 11:52 |
|
jweston_ joined #evergreen |
| 12:09 |
Dyrcona |
sandbergja|2: You'd have to provide an implementation of regexp_count() for the old postgresql versions, I guess. |
| 12:15 |
sandbergja|2 |
Would it be better to simply CREATE OR REPLACE FUNCTION regexp_count, or can I provide a wrapper function that can check the pg version and do the appropriate logic (the built-in function if it exists, our own implementation otherwise)? |
| 12:16 |
|
jihpringle joined #evergreen |
| 12:28 |
Dyrcona |
sandbergja|2: You probably want to check the Pg version and we'll probably want an alternate name for the local implementation of regexp_count so it won't cause errors if someone upgrades their database. Otherwise, we'd need release notes warning to drop the function before upgrading the db. |
| 12:29 |
sandbergja|2 |
that makes sense. Thanks, Dyrcona! |
| 12:29 |
sandbergja|2 |
Dyrcona++ |
| 12:29 |
Dyrcona |
I don't know if we have run into this with functions much, but with some datatypes or things like that we've usually made our own implementation that works in all Pg versions. There might already be a place or two in the schema set up where we check pg versions, but I'm not sure. |
| 12:36 |
csharp_ |
sandbergja|2: Dyrcona: we would really only want to worry about PG 14 since PG 13 is only supported through mid November and those before are already out of support |
| 12:37 |
sandbergja|2 |
charp_++ |
| 12:37 |
* csharp_ |
says the guy running PG 11 forevah |
| 12:38 |
csharp_ |
planning to upgrade PG later in the fall |
| 12:38 |
csharp_ |
not sure if 14 has any active orgs running it |
| 12:39 |
Dyrcona |
We're on Pg 16 in production. I have Pg 17 on some test servers. I've never used Pg 14 much except for a little light testing. |
| 12:40 |
jeffdavis |
We're on 14. |
| 12:40 |
csharp_ |
yeah, seems like most sites kind of stayed on PG 10/11, then moved past 15 maybe, but that's anecdotal based on not much information |
| 12:40 |
csharp_ |
ha! disproven out of the gate! |
| 12:49 |
|
Bmagic_ joined #evergreen |
| 12:50 |
|
scottangel_ joined #evergreen |
| 12:52 |
jeffdavis |
I guess we need to upgrade our Postgres next year. |
| 12:52 |
* jeffdavis |
sighs heavily |
| 12:53 |
|
jweston joined #evergreen |
| 12:56 |
|
jonadab joined #evergreen |
| 12:59 |
|
dluch joined #evergreen |
| 12:59 |
|
degraafk joined #evergreen |
| 13:13 |
|
book` joined #evergreen |
| 13:14 |
|
jonadab joined #evergreen |
| 13:20 |
|
mmorgan joined #evergreen |
| 14:03 |
JBoyer |
I donm't think there's an official stance on how to support multiple versions, but unofficially I'd personally say do not ever try to define a system function just in case, and if 12 (or whatever) is the oldest version of pg we support then everything has to be written to work on that version. |
| 14:04 |
JBoyer |
(in other words, you can polyfill in JS, but not very well in SQL) |
| 14:14 |
sandbergja|2 |
JBoyer: to check my understanding, in this case you would recommend that we create our own implementation (maybe we call it something like evergreen.regexp_matches_count), and use it consistently across all pg versions, even ones that have regexp_count available? |
| 14:17 |
|
jihpringle joined #evergreen |
| 14:17 |
JBoyer |
If we need whatever that does and want it to run on older pg, yeah. It can either be thrown away or just changed to call the built-in once 15 is the oldest thing we support. |
| 14:18 |
JBoyer |
That should also keep results consistent across versions rather than things perhaps behaving one way on pg 15+ and different on pg 14- (probably not a big threat for this func, but in general) |
| 14:20 |
sandbergja|2 |
gotcha |
| 14:20 |
sandbergja|2 |
JBoyer++ |
| 14:23 |
csharp_ |
JBoyer++ |
| 14:50 |
|
mantis joined #evergreen |
| 14:52 |
mantis |
does anyone know what the target column within action_trigger.event refers to for autorenewal notices? |
| 14:53 |
csharp_ |
mantis: that would be the circ |
| 14:58 |
mantis |
csharp++ |
| 16:40 |
Dyrcona |
mantis1: you can find the type of the target of any event by retrieving the core_type from action_trigger.hook for the event_definition. |
| 16:58 |
|
mantis left #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 17:50 |
|
jihpringle joined #evergreen |
| 20:48 |
|
tsadok joined #evergreen |
