Hello,
I would like to submit a patch so that the
COPY statement can import data into a view.
(Maybe if this works I'll see about copying
out of a view.)
Rather than spend a whole lot of time figuring
out all the calls to use and all the detail,
I'm going to go ahead and post now. That way
if
On 04/19/2007 08:41:55 AM, Karl O. Pinc wrote:
I would like to submit a patch so that the
COPY statement can import data into a view.
2) Allocate memory for char* and construct an
'INSERT ...' statement corresponding
to the COPY command that inserts into the view.
(Just how much memory
Karl O. Pinc wrote:
(Maybe if this works I'll see about copying
out of a view.)
You know we already have
COPY (SELECT ...) TO ...
don't you?
cheers
andrew
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Karl O. Pinc wrote:
On 04/19/2007 08:41:55 AM, Karl O. Pinc wrote:
I would like to submit a patch so that the
COPY statement can import data into a view.
2) Allocate memory for char* and construct an
'INSERT ...' statement corresponding
to the COPY command that inserts into the view.
Karl O. Pinc [EMAIL PROTECTED] writes:
Rather than spend a whole lot of time figuring
out all the calls to use and all the detail,
I'm going to go ahead and post now. That way
if this is simply not going to fly I don't have
to spend any more time on it. Otherwise,
I'll post more as I work
On 04/19/2007 09:33:44 AM, Andrew Dunstan wrote:
Karl O. Pinc wrote:
(Maybe if this works I'll see about copying
out of a view.)
You know we already have
COPY (SELECT ...) TO ...
don't you?
Sure. It'd just be syntatic suger for the
COPY (SELECT ...) form, so end-users
don't have to
On 04/19/2007 09:39:18 AM, Alvaro Herrera wrote:
I'm not sure the plan is OK as stated. You wouldn't want to force to
parse the query again for each row. Rather, create a prepared
statement
(already parsed, because you obtain it from the parsetree stored in
the
INSERT rule) to pass to the
Gregory Stark wrote:
Karl O. Pinc [EMAIL PROTECTED] writes:
Rather than spend a whole lot of time figuring
out all the calls to use and all the detail,
I'm going to go ahead and post now. That way
if this is simply not going to fly I don't have
to spend any more time on it.
Karl O. Pinc wrote:
On 04/19/2007 09:39:18 AM, Alvaro Herrera wrote:
I'm not sure the plan is OK as stated. You wouldn't want to force to
parse the query again for each row. Rather, create a prepared
statement
(already parsed, because you obtain it from the parsetree stored in
the
Alvaro Herrera [EMAIL PROTECTED] writes:
The threads to updatable views have concluded rejecting the patches, and
with ideas that require rather extensive rewriting of the rule manager,
I have some ideas on a different approach to this if anyone's thinking of
starting fresh but I had the
Gregory Stark wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
The threads to updatable views have concluded rejecting the patches, and
with ideas that require rather extensive rewriting of the rule manager,
I have some ideas on a different approach to this if anyone's thinking of
Alvaro Herrera [EMAIL PROTECTED] writes:
What ideas?
Basically I think what we should do is extend SQL to support things like
UPDATE (subquery) SET ...
DELETE FROM (subquery) WHERE ...
Ie, do the update-able view magic in the planner and executor rather than in
the rewriter. Then the
12 matches
Mail list logo
