From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Brent Verner <brent(at)rcfile(dot)org> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Problem reloading regression database |
Date: | 2002-01-13 20:17:53 |
Message-ID: | 28148.1010953073@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Brent Verner <brent(at)rcfile(dot)org> writes:
> I fixed this by making an int* mapping from specified collist
> position to actual rd_att->attrs position.
Sounds better.
> I'm still a bit^W^W lost as hell on how the column default magic
> happens.
I'd say use build_column_default() in src/backend/optimizer/prep/preptlist.c
to set up a default expression (possibly just NULL) for every column
that's not supplied by the input. That routine's not exported now, but
it could be, or perhaps it should be moved somewhere else. (Suggestions
anyone? Someplace in src/backend/catalog might be a more appropriate
place for it.)
Then in the per-tuple loop you use ExecEvalExpr, or more likely
ExecEvalExprSwitchContext, to execute the default expressions.
The econtext wanted by ExecEvalExpr can be had from the estate
that CopyFrom already creates; use GetPerTupleExprContext(estate).
You'll need to verify that you have got the memory context business
right, ie, no memory leak across rows. I think the above sketch is
sufficient, but check it with a memory-eating default expression
evaluated for a few million input rows ... and you are doing your
testing with --enable-cassert, I trust, to catch any dangling pointers.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew Kirkwood | 2002-01-13 21:14:38 | Re: mysql-pgsql comparison |
Previous Message | Tom Lane | 2002-01-13 19:51:33 | Re: mysql-pgsql comparison |