Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] 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 ...
Zoltan Boszormenyi írta:
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
--On Montag, August 21, 2006 02:07:41 -0400 Alvaro Herrera
[EMAIL PROTECTED] wrote:
So, I'll appreciate if somebody else takes the responsability to fix the
remaining issues. I've put a lot of XXX's and some FIXME's. Some
functions are in need of some comments as well.
While working on
Bernd Helmle [EMAIL PROTECTED] writes:
While working on Alvaro's suggestions to fix the code i got the opinion
that we need to reject any attempts to name a user defined rule
as
_INSERT
_NOTHING_INSERT
_DELETE
_NOTHING_DELETE
_UPDATE
_NOTHING_UPDATE
If the code is dependent on
On 8/24/06, Tom Lane [EMAIL PROTECTED] wrote:
Bernd Helmle [EMAIL PROTECTED] writes:
While working on Alvaro's suggestions to fix the code i got the opinion
that we need to reject any attempts to name a user defined rule
as
_INSERT
_NOTHING_INSERT
_DELETE
_NOTHING_DELETE
_UPDATE
Zoltan Boszormenyi írta:
Zoltan Boszormenyi írta:
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
--On Donnerstag, August 24, 2006 11:02:43 -0500 Jaime Casanova
[EMAIL PROTECTED] wrote:
Actually the code delete implicit rules based on a field added to
pg_rewrite but that catalog has a unique index on ev_class, rulename:
pg_rewrite_rel_rulename_index UNIQUE, btree (ev_class, rulename)
i
