Re: [HACKERS] [pgsql-advocacy] GSoC 2014 - mentors, students and admins

W dniu 27.02.2014 22:25, Thom Brown pisze: > On 27 February 2014 21:08, David Fetter > 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 not too fre

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

ution: changing Var structure and do the "copy" like now (in mutator and callback) but w/o the condition 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). R

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

NG"). We don't want to make "BEFORE" and "AFTER" restricted keywords. Now most of the code means "don't touch these because they are not real" :) If anyone has the fresh idea to it better, please write it by mail, I don't have more ideas how to

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

turning_clause_references(PlannerInfo *root, > resultRelation, > rtoffset); > > + bind_returning_variables(rlist, before_index, after_index); > pfree(itlist); > &

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

fore_index, after_index); > ^ > 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.

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

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 RT

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

ment about 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 ---

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

fails after trying to fix 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 ind

Re: [HACKERS] Patch to add support of "IF NOT EXISTS" to others "CREATE" statements

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 Defi

Re: [HACKERS] Patch to add support of "IF NOT EXISTS" to others "CREATE" statements

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 mailing

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

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 chang

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

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

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

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 +++ b/doc/

Re: [HACKERS] compiler warning in UtfToLocal and LocalToUtf (conv.c)

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 (pgsql-hackers@postgresql.or

[HACKERS] compiler warning in UtfToLocal and LocalToUtf (conv.c)

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 func

Re: [HACKERS] [v9.4] row level security

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 subs

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

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 tu

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

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 @@ -194,1

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

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 swi

[HACKERS] RETURNING syntax for COPY

triggers invoke 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 Trzcion

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

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

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

rt1 r set a = a + 1 returning XXX into r; raise notice '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

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

th any other 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

Re: [HACKERS] GSOC13 proposal - extend RETURNING syntax

ING old.foo; If it returns old value, it'll break capability. If it returns new 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

[HACKERS] GSOC13 proposal - extend RETURNING syntax

SERT?). Additionally 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