> 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@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
