W dniu 27.02.2014 22:25, Thom Brown pisze:
On 27 February 2014 21:08, David Fetter da...@fetter.org
mailto:da...@fetter.org wrote:
For MADlib, no. Are you asking for mentors in general?
Ah yes, I should clarify. Yes, mentors in general.
In general I can help but I'm not sure if I'm
statement (for the new fields). I
think it might need to modify more places in code because of comparing
vars (maybe we'd need to include new fields while comparision).
Regards,
Karol Trzcionka
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
to solve it.
This patch also has significant style issues.
I'll try to fix it soon.
Regards,
Karol Trzcionka
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
or of them should be fixed?
I think it is safe, it is the first and the last index. On each level of
statement there can be (at most) the only one before and one after
alias.
Regards,
Karol Trzcionka
diff --git a/doc/src/sgml/ref/update.sgml b/doc/src/sgml/ref/update.sgml
index 90b9208..eba35f0 100644
bind_returning_variables
- Remove unneeded code in fix_join_expr_mutator (it was changing varno
of RTE_BEFORE - now there is not any var with varno assigned to it)
Regards,
Karol Trzcionka
diff --git a/doc/src/sgml/ref/update.sgml b/doc/src/sgml/ref/update.sgml
index 90b9208..eba35f0 100644
--- a/doc/src/sgml
W dniu 20.08.2013 16:47, Karol Trzcionka pisze:
Thank you for the review and tests. New version introduce a lot of
improvements:
- Fix regression test for view (wrong table_name)
- Add regression test for inheritance
- Delete hack in initsplan.c (now we ignore all RTE_BEFORE
);
^
setrefs.c:1957:21: note: ‘before_index’ was declared here
int after_index=0, before_index;
^
Right, my mistake. Sorry and thanks. Fixed.
Regards,
Karol Trzcionka
diff --git a/doc/src/sgml/ref/update.sgml b/doc/src/sgml/ref/update.sgml
index 90b9208
the rejected chunk of the
patch.
It fails because the HINT was changed, fixed.
That version merges some nested ifs left over from earlier work.
Regards,
Karol Trzcionka
diff --git a/doc/src/sgml/ref/update.sgml b/doc/src/sgml/ref/update.sgml
index 90b9208..eba35f0 100644
--- a/doc/src/sgml/ref/update.sgml
W dniu 26.07.2013 02:44, Fabrízio de Royes Mello pisze:
Should be... I fix that in attached patch.
Hello, as I can see there are more inconsistent places.
First style:
OperatorCreate
---
Second style:
ProcedureCreate
TypeCreate
DefineTSParser
DefineType
DefineEnum
---
Third style:
CreateCast
Hello,
patch works fine but is there any reason to comparing each ifNotExists
in different way?
i.e.
ProcedureCreate
if (!ifNotExists)
...
else
{
...
return
}
TypeCreate
if (ifNotExists)
{
...
return
}
...
---
Shouldn't it be more consistent?
Regards,
Karol
--
Sent via pgsql-hackers
W dniu 23.07.2013 06:22, David Fetter pisze:
What problem or problems did you notice, and what did you change to
fix them?
UPDATE ... FROM generated ERROR: variable not found in subplan
target lists. I've added some workaround in add_vars_to_targetlist:
- if it is an after - simple change
I've noticed problem with UPDATE ... FROM statement. Fix in new version.
Regards,
Karol
diff --git a/doc/src/sgml/ref/update.sgml b/doc/src/sgml/ref/update.sgml
index 90b9208..eba35f0 100644
--- a/doc/src/sgml/ref/update.sgml
+++ b/doc/src/sgml/ref/update.sgml
@@ -194,12 +194,27 @@ UPDATE [ ONLY ]
New version:
- fix returning after values if there are not before
- add more regression tests
I'd like to hear/read any feedback ;)
Regards,
Karol
diff --git a/doc/src/sgml/ref/update.sgml b/doc/src/sgml/ref/update.sgml
index 90b9208..eba35f0 100644
--- a/doc/src/sgml/ref/update.sgml
+++
Current head 4cbe3ac3e86790d05c569de4585e5075a62a9b41 - patch applies
correct (only change needed in parallel_schedule).
However it fails on own regression tests (other tests pass).
Regards,
Karol
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Hello,
in the current master head (4cbe3ac3e86790d05c569de4585e5075a62a9b41),
I've noticed the compiler warnings in src/backend/utils/mb/conv.c
conv.c: In function ‘UtfToLocal’:
conv.c:252:23: error: ‘iutf’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
...
conv.c: In
W dniu 19.07.2013 02:42, Tom Lane pisze:
Hm, what compiler version are you using? I've never seen such a
warning (and that code hasn't changed in some time).
gcc version 4.8.1 20130612 (Red Hat 4.8.1-2) (GCC)
Regards,
Karol
--
Sent via pgsql-hackers mailing list
Next version:
- cleanup
- regression test
- fix issue reported by johto (invalid values in parallel transactions)
I would like more feedback and comments about the patch, as some parts
may be too hacky.
In particular, is it a problem that I update a pointer to planSlot? In
my patch, it points to
Updated patch:
- include sgml
- fix all compiler warnings
- some cleanup
- fix correctness of feature
Regards,
Karol
diff --git a/doc/src/sgml/ref/update.sgml b/doc/src/sgml/ref/update.sgml
index 90b9208..eba35f0 100644
--- a/doc/src/sgml/ref/update.sgml
+++ b/doc/src/sgml/ref/update.sgml
@@
Hello,
according to my mentor's suggestion, I send first PoC patch of
RETURNING AFTER/BEFORE statement. Some info:
- it is early version - more hack PoC than RC patch
- AFTER in this version works as decribed before but it returns row
after update but before post-update before (to be fixed or
COPY FROM ... RETURNING BEFORE.* - returns all values copied to table
before triggers (all raw values from file)
COPY TO ... RETURNING table_name.* - returns all values from table
COPY TO ... RETURNING AFTER.*/BEFORE.* - the same
What do you think about?
Regards,
Karol Trzcionka
--
Sent via
NEW and OLD values will be reserved keywords (it might be
some capability problem since in new PostgreSQL it isn't reserved -
however standard says it is and in old PgSQL it was).
I'd like to hear (read) yours feedback about syntax and/or implement
issues related to this proposal.
Regards,
Karol
value
(as now), there is no possibility to get old value (and user cries
because of broken feature).
Regards,
Karol Trzcionka
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
statements.
Regards,
Karol Trzcionka
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
'r = %', r; return null;
end; $f$;
Regards,
Karol Trzcionka
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
W dniu 02.05.2013 23:34, Gavin Flower pisze:
I prefer 'PRIOR 'AFTER' as the both have the same length
- but perhaps that is just me! :-)
I think it doesn't matter at now because PRIOR has the same problems as
BEFORE ;)
Regards,
Karol
25 matches
Mail list logo
