Re: [HACKERS] Getting OID in psql of recent insert

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "PostgreSQL-development"(at)candle(dot)pha(dot)pa(dot)us, pgsql-hackers(at)postgreSQL(dot)org, peter_e(at)gmx(dot)net
Subject: Re: [HACKERS] Getting OID in psql of recent insert
Date: 1999-11-19 04:16:13
Message-ID: 199911190416.XAA24427@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> If you want to attack this, I'd suggest thinking a little larger than
> just the last-OID problem. I'd like to be able to save off both
> insertion OIDs and values extracted by SELECTs into named variables
> of some sort, and then insert those values into as many later commands
> as I want. Right now there's no way to do any such thing in a psql
> script; you have to move up a level of difficulty into ecpg or pgtcl
> or even C code if your application needs this. Plain psql scripts
> would become substantially more powerful if psql had a capability
> like this.

Yes, I understand. The new psql has the ability to have variables, so
this seems like a natural use for this:

testdb=> \set foo bar

Maybe we could have:

testdb=> \set foo lastoid

testdb=> \echo "foo is now ${foo}."

Seems those variables are not available in queries, though.

> OTOH: we shouldn't ask psql to do everything under the sun. I'd
> certainly think that it'd be unreasonable to try to do conditional
> evaluation or looping in psql scripts, for instance. Maybe the right
> answer is to teach people a little bit about using honest-to-goodness
> scripting languages when their applications reach this level of
> complexity. How much daylight is there between needing script
> variables and needing control flow, do you think?

I think I agree, but a powerful psql interface is very important for any
database.

> PS: not relevant to your main point, but to your example: I think it's
> a real bad idea to teach people to use OIDs as foreign keys. That'll
> create all kinds of trouble when it comes time to dump/reload their
> database. Better to tell them to use SERIAL columns as keys. Not so
> incidentally, we have currval() already...

OK, I am dealing with this in the book. What are oids good for then?

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-11-19 04:16:30 Re: [HACKERS] pg version date file
Previous Message Tom Lane 1999-11-19 04:14:35 Re: [HACKERS] Primary key requires SERIAL