Re: BUG #10972: string_agg function incorrectly concatenating varying delimiter

Hi Tom,

I just read the Wikipedia article on you, fun.  Glad to make your acquainta=
nce.  My business partner, Dave Yarnall, went to Carnegie Mellon (CCed).

I suppose principles can be relative, but I'll assume you mean good princip=
les and give it a shot.

Primarily, I'd consider whether another function uses non-deterministic row=
s for its evaluation.  I could be wrong, but I don't think any other functi=
on uses two different rows results within a single function evaluation.  Ev=
en aggregates, such as string_agg, evaluate one row at a time which is a we=
ll-known behavior.

A similar paradigm might be in general programming if a compiled program ra=
ndomly chose values off of the stack to place as a parameter into a method =
call (function 3's parameters are passed into function2).  An odd and unexp=
ected behavior for the SQL language and really any language, I think.  Alth=
ough, it is quite creative.

It sounds like you've quickly isolated the line within the source.  In an i=
nterest in learning more about the code, would you mind pointing my partner=
 and I to the line for this bug?

Thanks,
Jeff

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]=20
Sent: Wednesday, July 16, 2014 7:20 AM
To: Jeff Fischer
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #10972: string_agg function incorrectly concatenati=
ng varying delimiter

jeff@goaldriven.com writes:
> Running the query below will show how the delimiter for the current=20
> row is actually the subsequent rows delimiter.

Hmm, well, the documentation for string_agg doesn't say what happens when t=
he "delimiter" argument varies across rows; but a quick look at the code fi=
nds that the first-call delimiter isn't actually used at all, and on subseq=
uent calls the delimiter is appended to the running result before the assoc=
iated value is.  Which seems to me to be at least as reasonable, and certai=
nly a great deal easier to implement, as what you seem to have in mind.  Ca=
n you offer a principled argument why it should be the other way around?

            regards, tom lane