Andrew Dunstan writes:
> what is even worse is that this procedure doesn't take any care at all
> of the ordering rule for even numbered enum oids.
Good point. You really should use ALTER TYPE ADD VALUE, on versions
where that's available.
regards, tom lane
--
Sent v
On 12/19/2012 11:31 AM, Tom Lane wrote:
enum_add is all right as long as you are careful to commit its
transaction before inserting the new value anywhere.
It's not really all right for post-9.0 versions. For example, this is wrong:
--postgres 9.2 or higher
Andres Freund writes:
> On 2012-12-19 16:51:32 +0100, Bernhard Schrader wrote:
>> Well, so far i can say, we dont use ALTER TYPE ADD VALUE. We use some more
>> or less changed enum_add and enum_del (Which are appended at the end) to be
>> able to change enums within transactions.
> That explains
On 12/19/2012 10:56 AM, Andres Freund wrote:
On 2012-12-19 16:51:32 +0100, Bernhard Schrader wrote:
Hello again,
well, still everything is working.
What information do you need to get into this issue?
Well, so far i can say, we dont use ALTER TYPE ADD VALUE. We use some more
or less changed
On 2012-12-19 16:51:32 +0100, Bernhard Schrader wrote:
> Hello again,
>
> well, still everything is working.
>
> What information do you need to get into this issue?
>
> Well, so far i can say, we dont use ALTER TYPE ADD VALUE. We use some more
> or less changed enum_add and enum_del (Which are app
Hello again,
well, still everything is working.
What information do you need to get into this issue?
Well, so far i can say, we dont use ALTER TYPE ADD VALUE. We use some
more or less changed enum_add and enum_del (Which are appended at the
end) to be able to change enums within transactions.
On 12/18/2012 09:38 PM, Tom Lane wrote:
Andrew Dunstan writes:
People have been known to hack pg_enum on their own, especially before
we added enum extension.
Of course, if they do that they get to keep both pieces.
Yeah ... this would be very readily explainable if there had been a
manual del
Andrew Dunstan writes:
> People have been known to hack pg_enum on their own, especially before
> we added enum extension.
> Of course, if they do that they get to keep both pieces.
Yeah ... this would be very readily explainable if there had been a
manual deletion from pg_enum somewhere along t
On 12/18/2012 02:58 PM, Tom Lane wrote:
Andrew Dunstan writes:
He's upgrading from 9.0, which didn't have enum extension at all, and
where odd enums didn't mean anything special.
Really? The noncontiguous pg_enum OIDs shown in
http://archives.postgresql.org/pgsql-hackers/2012-12/msg01089.php
Andrew Dunstan writes:
> He's upgrading from 9.0, which didn't have enum extension at all, and
> where odd enums didn't mean anything special.
Really? The noncontiguous pg_enum OIDs shown in
http://archives.postgresql.org/pgsql-hackers/2012-12/msg01089.php
suggest strongly that *something's* be
On 12/18/2012 02:34 PM, Tom Lane wrote:
Andres Freund writes:
On 2012-12-18 13:24:12 -0500, Tom Lane wrote:
Does the table being updated have any indexes on enum columns? I'm
suspicious that the bogus OID is in an index page somewhere, and not
in the table at all.
I already wondered whether
Andres Freund writes:
> On 2012-12-18 13:24:12 -0500, Tom Lane wrote:
>> Does the table being updated have any indexes on enum columns? I'm
>> suspicious that the bogus OID is in an index page somewhere, and not
>> in the table at all.
> I already wondered whether it could be a problem caused by
On 2012-12-18 13:24:12 -0500, Tom Lane wrote:
> Bernhard Schrader writes:
> > Beside of that, we tested a little bit more with the failing query:
> > The statement which is causing the error is a big UPDATE-statement with
> > FROM. After some testing we figured out that the subselect in the
> > FR
On 12/18/2012 01:24 PM, Tom Lane wrote:
Bernhard Schrader writes:
Beside of that, we tested a little bit more with the failing query:
The statement which is causing the error is a big UPDATE-statement with
FROM. After some testing we figured out that the subselect in the
FROM-clause is working
Bernhard Schrader writes:
> Beside of that, we tested a little bit more with the failing query:
> The statement which is causing the error is a big UPDATE-statement with
> FROM. After some testing we figured out that the subselect in the
> FROM-clause is working fine. And if we simplify the UPDA
On 12/18/2012 05:22 PM, Bruce Momjian wrote:
On Tue, Dec 18, 2012 at 10:52:46AM -0500, Andrew Dunstan wrote:
The translations from oid to label are in pg_enum, but it looks like
somehow you have lost that mapping. I'm not sure what you've done
but AFAICT pg_upgrade is doing the right thing.
I j
On Tue, Dec 18, 2012 at 10:52:46AM -0500, Andrew Dunstan wrote:
> The translations from oid to label are in pg_enum, but it looks like
> somehow you have lost that mapping. I'm not sure what you've done
> but AFAICT pg_upgrade is doing the right thing.
>
> I just did this (from 9.0 to 9.2) and the
On 12/18/2012 03:45 AM, Bernhard Schrader wrote:
On 12/18/2012 02:41 AM, Bruce Momjian wrote:
On Mon, Dec 17, 2012 at 12:14:29PM +0100, Bernhard Schrader wrote:
Hello together,
last thursday I upgraded one of our 9.0.6 postgresql servers to
9.2.2 with pg_upgrade. So far everything seemed to w
On 12/18/2012 02:41 AM, Bruce Momjian wrote:
On Mon, Dec 17, 2012 at 12:14:29PM +0100, Bernhard Schrader wrote:
Hello together,
last thursday I upgraded one of our 9.0.6 postgresql servers to
9.2.2 with pg_upgrade. So far everything seemed to work but we now
disco
On 12/18/2012 02:41 AM, Bruce Momjian wrote:
On Mon, Dec 17, 2012 at 12:14:29PM +0100, Bernhard Schrader wrote:
Hello together,
last thursday I upgraded one of our 9.0.6 postgresql servers to
9.2.2 with pg_upgrade. So far everything seemed to work but we now
discover problems with the enum type
On Mon, Dec 17, 2012 at 12:14:29PM +0100, Bernhard Schrader wrote:
> Hello together,
>
> last thursday I upgraded one of our 9.0.6 postgresql servers to
> 9.2.2 with pg_upgrade. So far everything seemed to work but we now
> discover problems with the enum types. If we run one specific query
> it b
On Mon, Dec 17, 2012 at 12:14:29PM +0100, Bernhard Schrader wrote:
> Hello together,
>
> last thursday I upgraded one of our 9.0.6 postgresql servers to
> 9.2.2 with pg_upgrade. So far everything seemed to work but we now
> discover problems with the enum types. If we run one specific query
> it b
22 matches
Mail list logo
