pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Thom Brown <thom@linux.com>
Cc: Dimitri Fontaine <dimitri@2ndquadrant.fr>
Subject: Re: Command Triggers, patch v11
Date: Sun, 18 Mar 2012 14:29:30 -0400
Message-ID: <18353.1332095370@sss.pgh.pa.us> (raw)
In-Reply-To: <201203172326.53461.andres@anarazel.de>
References: <m24nufq466.fsf@2ndQuadrant.fr>
	<9503.1332006327@sss.pgh.pa.us>
	<24814.1332021870@sss.pgh.pa.us>
	<201203172326.53461.andres@anarazel.de>

BTW, I've been looking through how to do what I suggested earlier to get
rid of the coziness and code duplication between CreateTableAs and the
prepare.c code; namely, let CreateTableAs create a DestReceiver and then
call ExecuteQuery with that receiver.  It appears that we still need at
least two bits of added complexity with that approach:

1. ExecuteQuery still has to know that's a CREATE TABLE AS operation so
that it can enforce that the prepared query is a SELECT.  (BTW, maybe
this should be weakened to "something that returns tuples", in view of
RETURNING?)

2. Since ExecuteQuery goes through the Portal machinery, there's no way
for it to pass in eflags to control the table OIDs setup.  This is
easily solved by adding an eflags parameter to PortalStart, which
doesn't seem too awful to me, since the typical caller would just pass
zero.  (ExecuteQuery would also have to know about testing
interpretOidsOption to compute the eflags to use, unless we add an
eflags parameter to it, which might be the cleaner option.)

In short I'm thinking: add an eflags parameter to PortalStart, and add
both an eflags parameter and a "bool mustReturnTuples" parameter to
ExecuteQuery.  This definitely seems cleaner than the current
duplication of code.

			regards, tom lane



view thread (115+ messages)  latest in thread

Message-ID: <18353.1332095370@sss.pgh.pa.us>
Permalink:  ../18353.1332095370@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/18353.1332095370@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, thom@linux.com, dimitri@2ndquadrant.fr
  Subject: Re: Command Triggers, patch v11
  In-Reply-To: <18353.1332095370@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox