Skip site navigation (1) Skip section navigation (2)


From: Zoltan Boszormenyi <zboszor(at)dunaweb(dot)hu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] COPY view
Date: 2006-08-24 09:53:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Tom Lane írta:
> Zoltan Boszormenyi <zboszor(at)dunaweb(dot)hu> writes:
>> How about the callback solution for the SELECT case
>> that was copied from the original? Should I consider
>> open-coding in copy.c what ExecutorRun() does
>> to avoid the callback?
> Adding a DestReceiver type is a good solution ... although that static
> variable is not.  Instead define a DestReceiver extension struct that
> can carry the CopyState pointer for you.


>   You could also consider
> putting the copy-from-view-specific state fields into DestReceiver
> instead of CopyState, though this is a bit asymmetric with the relation
> case so maybe it's not really cleaner.

Left it alone for now.

> BTW, lose the tuple_to_values function --- it's an extremely bad
> reimplementation of heap_deform_tuple.


>   copy_dest_printtup also seems
> coded without regard for the TupleTableSlot access API (read printtup()
> to see what to do instead).

I am still interpreting it. Can you give me some hints
besides using slot_getallattrs(slot)?

>   And what's the point of factoring out the
> heap_getnext loop as CopyRelationTo?  It's not like that lets you share
> any more code.  The inside of the loop, ie what you've called
> CopyValuesTo, is the sharable part.


The option parsing and error checking is now common.

I also changed it to use transformStmt() in analyze.c.
However, both the UNION and sunselect cases give me
something like this:

ERROR:  could not open relation 1663/16384/16723: No such file or directory

What else can I do with it?

Best regards,
Zoltán Böszörményi

Attachment: pgsql-copyselect-4.patch.gz
Description: application/x-tar (10.0 KB)

In response to


pgsql-hackers by date

Next:From: Martijn van OosterhoutDate: 2006-08-24 09:57:15
Subject: Re: invalid byte sequence ?
Previous:From: Gregory StarkDate: 2006-08-24 09:41:37
Subject: Re: Tricky bugs in concurrent index build

pgsql-patches by date

Next:From: Zoltan BoszormenyiDate: 2006-08-24 10:05:28
Subject: Re: [HACKERS] COPY view
Previous:From: Jim C. NasbyDate: 2006-08-24 09:19:21
Subject: Re: [PATCHES] selecting large result sets in psql using

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group