Re: [HACKERS] Call for objections: put back OIDs in CREATE TABLE AS/SELECT
Ross, you make some powerful arguments here. Probably the most significant was the idea that you need a unique identifier for every row, and it should be of a consistent type, which primary key is not. We clearly need a GUC parameter to turn on/off oids. But it seems we will always need the ability to return something like OID to the user if the user wants it. What it seems we need is a 64-bit oid someday. As an aside, as Tom already said, the 7.3.X patch is just to make CREATE TABLE and CREATE TABLE AS behave the same for OIDs. It does not effect our defaults for future releases, though this little change in 7.3.0 did show use that some folks are using OID and did miss them. --- Ross J. Reedstrom wrote: On Thu, Jan 23, 2003 at 10:03:28AM -0500, Tom Lane wrote: Curt Sampson [EMAIL PROTECTED] writes: I object. I personally think we should be moving towards not using OIDs as the default behaviour, inasmuch as we can, for several reasons: All these objections are global in nature, not specific to CREATE TABLE AS. The argument that persuaded me to do something here is that CREATE TABLE AS should not be different from CREATE TABLE's default behavior. I have no problem with moving towards lack-of-OIDs as the default behavior for both statements, in the long run, if we can get past the compatibility issues. But I don't think OIDs in user tables are costing us anything much, so I'm not prepared to take any big compatibility hit to change the default ... Agreed as to taking the compatability hit in the 7.3 branch (you _were_ talking about changing 7.3, weren't you?) But I think Curt and D'Arcy have a point: what OIDs are costing the DBAs and PostgreSQL developing community is the pain of having an 'almost' solution in place. OIDs have always been the unwanted child in PostgreSQL: the 'pure relational' people don't want them, and the Object people are misled into thinking we've got a _real_ object id. On the relational side, they've stood in for proper use of primary keys (as D'Arcy points out), partly because it's so _easy_ to misuse them that way: the wire protocol returns the OID for free in some cases, and the interface libraries make it easy to get at. So the immediate case, changing the default (in 7.3) to match the CREATE TABLE case makes sense. However, we need to wean developers off using OIDs. I've been working with Diedrich Vorberg on a thin python object relational mapping interface (his Object Relational Membrane - ORM) and this was a central problem: you _need_ a unique id for an object, and the oid seemed so natural ... So in the longer term, we need to provide a replacement. Arguably, the primary key for a table is the right replacement, but we don't _require_ a pkey, so what to do in cases where this isn't one? Also, the pkey can be _any_ column(s), of _any_ type, which could be inconvenient for returning as the result of an insert, for example (imagine a text field as pkey, with a _huge_ block of text just written into it ...) Ross ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for objections: put back OIDs in CREATE TABLE AS/SELECT INTO
Curt Sampson [EMAIL PROTECTED] writes: I object. I personally think we should be moving towards not using OIDs as the default behaviour, inasmuch as we can, for several reasons: All these objections are global in nature, not specific to CREATE TABLE AS. The argument that persuaded me to do something here is that CREATE TABLE AS should not be different from CREATE TABLE's default behavior. I have no problem with moving towards lack-of-OIDs as the default behavior for both statements, in the long run, if we can get past the compatibility issues. But I don't think OIDs in user tables are costing us anything much, so I'm not prepared to take any big compatibility hit to change the default ... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Call for objections: put back OIDs in CREATE TABLE AS/SELECT INTO
On Thu, Jan 23, 2003 at 10:03:28AM -0500, Tom Lane wrote: Curt Sampson [EMAIL PROTECTED] writes: I object. I personally think we should be moving towards not using OIDs as the default behaviour, inasmuch as we can, for several reasons: All these objections are global in nature, not specific to CREATE TABLE AS. The argument that persuaded me to do something here is that CREATE TABLE AS should not be different from CREATE TABLE's default behavior. I have no problem with moving towards lack-of-OIDs as the default behavior for both statements, in the long run, if we can get past the compatibility issues. But I don't think OIDs in user tables are costing us anything much, so I'm not prepared to take any big compatibility hit to change the default ... Agreed as to taking the compatability hit in the 7.3 branch (you _were_ talking about changing 7.3, weren't you?) But I think Curt and D'Arcy have a point: what OIDs are costing the DBAs and PostgreSQL developing community is the pain of having an 'almost' solution in place. OIDs have always been the unwanted child in PostgreSQL: the 'pure relational' people don't want them, and the Object people are misled into thinking we've got a _real_ object id. On the relational side, they've stood in for proper use of primary keys (as D'Arcy points out), partly because it's so _easy_ to misuse them that way: the wire protocol returns the OID for free in some cases, and the interface libraries make it easy to get at. So the immediate case, changing the default (in 7.3) to match the CREATE TABLE case makes sense. However, we need to wean developers off using OIDs. I've been working with Diedrich Vorberg on a thin python object relational mapping interface (his Object Relational Membrane - ORM) and this was a central problem: you _need_ a unique id for an object, and the oid seemed so natural ... So in the longer term, we need to provide a replacement. Arguably, the primary key for a table is the right replacement, but we don't _require_ a pkey, so what to do in cases where this isn't one? Also, the pkey can be _any_ column(s), of _any_ type, which could be inconvenient for returning as the result of an insert, for example (imagine a text field as pkey, with a _huge_ block of text just written into it ...) Ross ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Call for objections: put back OIDs in CREATE TABLE AS/SELECT INTO
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Why don't you just include them by default, otherwise if WITHOUT OIDS appears in the CREATE TABLE command, then don't include them ? Well, adding a WITHOUT OIDS option to CREATE TABLE AS would be a new feature, which I don't have the time/interest for. I won't do anything to preclude someone else implementing that, though ;-) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Call for objections: put back OIDs in CREATE TABLE AS/SELECT INTO
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Why don't you just include them by default, otherwise if WITHOUT OIDS appears in the CREATE TABLE command, then don't include them ? Well, adding a WITHOUT OIDS option to CREATE TABLE AS would be a new feature, which I don't have the time/interest for. I won't do anything to preclude someone else implementing that, though ;-) Oh, I thought it already had it from the CREATE TABLE bit... Does sound like it would be a good ultimate solution tho. Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Call for objections: put back OIDs in CREATE TABLE AS/SELECT INTO
Why don't you just include them by default, otherwise if WITHOUT OIDS appears in the CREATE TABLE command, then don't include them ? Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tom Lane Sent: Wednesday, 22 January 2003 4:12 AM To: [EMAIL PROTECTED] Subject: [HACKERS] Call for objections: put back OIDs in CREATE TABLE AS/SELECT INTO We've gotten a couple of complaints now about the fact that 7.3 doesn't include an OID column in a table created via CREATE TABLE AS or SELECT INTO. Unless I hear objections, I'm going to revert it to including an OID, and back-patch the fix for 7.3.2 as well. See discussion a couple days ago on pgsql-general, starting at http://archives.postgresql.org/pgsql-general/2003-01/msg00669.php regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
