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
Sorry for resubmitting this patch.
Just now I found a problem.
Instead of assigning initial sequence value to 1,
I assign LLONG_MAX to avoid the buffer overflow problem.
Please find the current version here.
Dhanaraj M wrote:
Hi all,
This patch was discussed a few months ago.
I could not com
--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 Al
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
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
I was looking over the "FIXME" marks within the information_schema.sql,
and the last ones left (after my previous patch) are for interval_type
and interval_precision. It looks to me as if the standard is
differentiating between datetime_precision and interval_precision (see
attached patch), so I pu
Greg Stark <[EMAIL PROTECTED]> writes:
> Updated patch. Fixed a few minor things, added documentation and regression
> tests. Unfortunately I can't test the regression tests because I get a
> segmentation fault earlier in the same file due to a GIN index build. So I
> haven't updated the "expected"
--On Donnerstag, August 24, 2006 11:00:45 -0400 Tom Lane
<[EMAIL PROTECTED]> wrote:
If the code is dependent on recognizing names to know what it's doing,
then I'd say you have a fundamentally broken approach. Consider adding
a flag column to pg_rewrite to distinguish these rules, instead.
T
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
11 matches
Mail list logo
