Re: How to Build Postgres in a Portable / Relocatable fashion?

2024-05-04 Thread grimy . outshine830
On Fri, May 03, 2024 at 11:27:12PM GMT, AJ ONeal wrote: > What I want to create (and provide) is a portable tarball that has > most of all what it needs in the tarball and will look for relevant > libraries relative to itself. Something that Just Works™ *almost* > anywhere (Ubuntu, Debian,

Re: pgBadger: Cannot find any log entries from systemd-journald

2024-03-05 Thread grimy . outshine830
On Tue, Mar 05, 2024 at 09:13:48AM +0100, Frank Lanitz wrote: I don't actually know pgbadger, but: > $ pgbadger --journalctl "journalctl -u postgresql.service" > LOG: Ok, generating html report...s: 0, events: 0 Try as root? Or is pgbadger a setuid program? -- Ian

Re: Content for talk on Postgres Type System at PostgresConf

2024-03-02 Thread grimy . outshine830
On Fri, Mar 01, 2024 at 03:25:35PM -0500, Tom Lane wrote: > No, what he showed was correct. I'm talking about a different facet > of the problem: > ... > Even if that took account of the exchange rate, it'd not be great. > But it doesn't; it's just the same digits reinterpreted with a new >

Re: Content for talk on Postgres Type System at PostgresConf

2024-03-01 Thread grimy . outshine830
On Thu, Feb 29, 2024 at 05:51:11PM -0500, Tom Lane wrote: > >> money is a fixed-point decimal value, the number of decimal > >> places is locale determined. I’m not aware of any particular > >> problems with that > > You forget about the currency symbol dynamic. Like with time zones > > the

Re: Content for talk on Postgres Type System at PostgresConf

2024-02-29 Thread grimy . outshine830
On Thu, Feb 29, 2024 at 10:11:03AM +0100, Laurenz Albe wrote: > It might be good to explain how "timestamp with time zone" works. > That's often confusing for beginners, because it is different from > other databases and arguably deviates from the SQL standard. The most confusing part is the

Re: Gradual migration from integer to bigint?

2023-09-30 Thread grimy . outshine830
On Sat, Sep 30, 2023 at 03:55:20PM +1000, James Healy wrote: > It did make me curious though: would it be possible for postgres to > support gradual migration from integer to bigint in a more > transparent way, where new and updated tuples are written as bigint, > but existing tuples can be read