On Sun, 1 Oct 2023 at 14:37, Tom Lane wrote:
> I think what you're asking for is a scheme whereby some rows in a
> table have datatype X in a particular column while other rows in
> the very same physical table have datatype Y in the same column.
> That is not happening, because there'd be no way
Triggers can be set for insert, update, delete, and truncate operations.
Alter table operations, like adding or dropping a column from a table, do
not cause an update trigger to fire but can be captured by an event trigger.
Are there any situations where the data in a table can be changed and the
p...@pfortin.com writes:
> I see the string "SET client_encoding = 'WIN1252';" in the dump -- some
> files come from a remote colleague; but this has never been an issue
> before...
Hah! If I create the test database with encoding WIN1252 then your
test fails as described. It *should* be complai
W dniu 30.09.2023 o 07:55, James Healy pisze:
...
We shouldn't have let them get so big, but that's a conversation
for another day.
Some are approaching overflow and we're slowly doing the work to
migrate to bigint. Mostly via the well understood "add a new id_bigint
column, populate on new tupl
On Sat, Sep 30, 2023 at 11:37 PM Tom Lane wrote:
> James Healy writes:
> > However it doesn't really address the question of a gradual migration
> > process that can read 32bit ints but insert/update as 64bit bigints. I
> > remain curious about whether the postgres architecture just makes that
>
On 10/1/23 12:04, Ireneusz Pluta wrote:
W dniu 30.09.2023 o 07:55, James Healy pisze:
...
We shouldn't have let them get so big, but that's a conversation
for another day.
Some are approaching overflow and we're slowly doing the work to
migrate to bigint. Mostly via the well understood "add a n
