Re: Any reason why the default_with_oids GUC is still there?

... or did we just forget to remove it?

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

On 21/09/10 04:18, Josh Berkus wrote:
> ... or did we just forget to remove it?

Backwards-compatibility? ;-) There hasn't been any pressing reason to
remove it.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On 9/20/10 10:59 PM, Heikki Linnakangas wrote:
> On 21/09/10 04:18, Josh Berkus wrote:
>> ... or did we just forget to remove it?
>
> Backwards-compatibility? ;-) There hasn't been any pressing reason to
> remove it.

Any application which needed it (like OpenACS) just got broken when we
removed add_missing_from. Let alone the typecasting changes in 8.3.

Personally, I find removing GUCS to be a worthwhile goal in itself. We
have well over 200 now.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

On 09/21/2010 05:15 PM, Josh Berkus wrote:
> On 9/20/10 10:59 PM, Heikki Linnakangas wrote:
>> On 21/09/10 04:18, Josh Berkus wrote:
>>> ... or did we just forget to remove it?
>> Backwards-compatibility? ;-) There hasn't been any pressing reason to
>> remove it.
> Any application which needed it (like OpenACS) just got broken when we
> removed add_missing_from. Let alone the typecasting changes in 8.3.

Umm, no. One of our customers has sponsored work to allow OpenACS to run
on 9.0[1] (they REALLY want to be able to use hot standby) ;-) One of my
tasks this week is to set up 9.0 for them on a VM where they will test
these changes. But default_with_oids is really quite a different issue.

cheers

andrew

[1] see <http://openacs.org/forums/message-view?message_id=3468735>

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> On 9/20/10 10:59 PM, Heikki Linnakangas wrote:
>> Backwards-compatibility? ;-) There hasn't been any pressing reason to
>> remove it.

> Any application which needed it (like OpenACS) just got broken when we
> removed add_missing_from. Let alone the typecasting changes in 8.3.

Huh? There's no reason to assume that those features are connected.

> Personally, I find removing GUCS to be a worthwhile goal in itself. We
> have well over 200 now.

Usually we don't remove GUCs (or other backwards-compatibility features)
until there's some positive reason to do so. I don't see one at the
moment for default_with_oids. Reducing the length of the GUC list by
0.5% doesn't seem like an adequate reason for possibly breaking old apps.

Mind you, it wouldn't take a *big* reason to persuade me to remove it.
But bigger than that.

regards, tom lane

I wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> On 9/20/10 10:59 PM, Heikki Linnakangas wrote:
>>> Backwards-compatibility? ;-) There hasn't been any pressing reason to
>>> remove it.

> Mind you, it wouldn't take a *big* reason to persuade me to remove it.
> But bigger than that.

Actually, I can think of a fairly sizable reason not to remove it:
pg_dump issues "SET default_with_oids" commands in its scripts, and
has done for lo these many years. So you'd be breaking backwards
compatibility with even-quite-recent dumps.

It'd be possible to work around that; for example, if you don't use
--single-transaction to restore the dump then you could just ignore
the errors. But it still is not something to just lightly break.

regards, tom lane

On Tue, 2010-09-21 at 18:05 -0400, Tom Lane wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
> > On 9/20/10 10:59 PM, Heikki Linnakangas wrote:
> >> Backwards-compatibility? ;-) There hasn't been any pressing reason to
> >> remove it.
>
> > Any application which needed it (like OpenACS) just got broken when we
> > removed add_missing_from. Let alone the typecasting changes in 8.3.
>
> Huh? There's no reason to assume that those features are connected.
>
> > Personally, I find removing GUCS to be a worthwhile goal in itself. We
> > have well over 200 now.
>
> Usually we don't remove GUCs (or other backwards-compatibility features)
> until there's some positive reason to do so. I don't see one at the
> moment for default_with_oids. Reducing the length of the GUC list by
> 0.5% doesn't seem like an adequate reason for possibly breaking old apps.
>
> Mind you, it wouldn't take a *big* reason to persuade me to remove it.
> But bigger than that.

The uninformed still use OIDs. They shouldn't.

Joshua D. Drake

>
> regards, tom lane
>

--
PostgreSQL.org Major Contributor
Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579
Consulting, Training, Support, Custom Development, Engineering
http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt

Tom Lane wrote:
> I wrote:
> > Josh Berkus <josh(at)agliodbs(dot)com> writes:
> >> On 9/20/10 10:59 PM, Heikki Linnakangas wrote:
> >>> Backwards-compatibility? ;-) There hasn't been any pressing reason to
> >>> remove it.
>
> > Mind you, it wouldn't take a *big* reason to persuade me to remove it.
> > But bigger than that.
>
> Actually, I can think of a fairly sizable reason not to remove it:
> pg_dump issues "SET default_with_oids" commands in its scripts, and
> has done for lo these many years. So you'd be breaking backwards
> compatibility with even-quite-recent dumps.
>
> It'd be possible to work around that; for example, if you don't use
> --single-transaction to restore the dump then you could just ignore
> the errors. But it still is not something to just lightly break.

Also, doesn't some SQL standard require oids, so we should have a way to
enable them by default for all tables?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> Actually, I can think of a fairly sizable reason not to remove it:
>> pg_dump issues "SET default_with_oids" commands in its scripts, and
>> has done for lo these many years. So you'd be breaking backwards
>> compatibility with even-quite-recent dumps.

> Also, doesn't some SQL standard require oids, so we should have a way to
> enable them by default for all tables?

Seems highly unlikely. If there is any requirement for unique row
identifiers in the spec, OIDs as currently implemented likely wouldn't
meet it anyway.

regards, tom lane

On tis, 2010-09-21 at 18:31 -0400, Bruce Momjian wrote:
> Also, doesn't some SQL standard require oids, so we should have a way
> to enable them by default for all tables?

From some DB2 example:

CREATE TYPE BusinessUnit_t AS
(Name VARCHAR(20),
Headcount INT);

CREATE TABLE BusinessUnit OF BusinessUnit_t
(REF IS oid USER GENERATED);

The DB2 documentation consistently refers to this column as "oid", but
there is no requirement to name it that way.

The SQL standard also contains this sentence:

Let OID be the name of the self-referencing column of S.

which refers to the thing defined in the example above, but "OID" is
just a placeholder here.

I think there was a mention of OIDs in the "SQL3" draft that eventually
became SQL99, but that's long past now. Current standards don't have
it, except in the, perhaps more generalized, form above.

Peter Eisentraut wrote:
> On tis, 2010-09-21 at 18:31 -0400, Bruce Momjian wrote:
> > Also, doesn't some SQL standard require oids, so we should have a way
> > to enable them by default for all tables?
>
> >From some DB2 example:
>
> CREATE TYPE BusinessUnit_t AS
> (Name VARCHAR(20),
> Headcount INT);
>
> CREATE TABLE BusinessUnit OF BusinessUnit_t
> (REF IS oid USER GENERATED);
>
> The DB2 documentation consistently refers to this column as "oid", but
> there is no requirement to name it that way.
>
> The SQL standard also contains this sentence:
>
> Let OID be the name of the self-referencing column of S.
>
> which refers to the thing defined in the example above, but "OID" is
> just a placeholder here.
>
> I think there was a mention of OIDs in the "SQL3" draft that eventually
> became SQL99, but that's long past now. Current standards don't have
> it, except in the, perhaps more generalized, form above.

Thanks for those details. I did remember it appearing at one point,
which I guess was SQL3.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +