Re: How to Build Postgres in a Portable / Relocatable fashion?
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, RedHat, Suse... maybe even Alpine). Alpine is based on musl (not glibc), so you're pretty much OOL at least on that point. Have you thought about using a container? -- Ian
Re: pgBadger: Cannot find any log entries from systemd-journald
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
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 > currency sign and possibly a different number of fractional digits. > This might be sort of tolerable if your database only ever deals in > one currency, but even then you'd likely want to lock down what that > currency is. Making it be controlled by a user-set GUC was probably > not a great idea. Yes, I get it now, thanks. Not useful, I agree. -- Ian
Re: Content for talk on Postgres Type System at PostgresConf
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 local session provides the context, not the stored data. > Yeah. The fact that the same stored value might look like 10.00 > euros to one session and 1000 yen to another one is pretty > catastrophic. The other nasty thing about money is that it's an > int64 so it can't represent more than 2^63 pennies (for whatever a > "penny" is). Now, that's still a Frickin Lot Of Money in any > non-hyperinflated currency, but it's the sort of restriction that > banks don't like to hear of. Lame excuse first: I have never used the money type, probably because I overheard a word like "catastrophic" in my early development :-) But, doesn't what Tom says above contradict Adrian's example session? Either the stored value is re-interpreted according to the locale context, or it isn't. IMO it would be *more* catastrophic if it wasn't, as it looks from Adrian's example. -- Ian
Re: Content for talk on Postgres Type System at PostgresConf
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 name :-P It is natural for a beginner -- and I am not that far from being a beginner -- to assume a data type with this name must store a time zone somehow. -- Ian
Re: Gradual migration from integer to bigint?
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 as integer? Language police: this is the *opposite* of "transparent". "trasparent" and "automated" are not synonyms. -- Ian
