Hello
2014-07-21 22:34 GMT+02:00 Jeff Fischer <jeff@goaldriven.com>:
> Hi Tom,
>
> I just read the Wikipedia article on you, fun. Glad to make your
> acquaintance. My business partner, Dave Yarnall, went to Carnegie Mellon
> (CCed).
>
> I suppose principles can be relative, but I'll assume you mean good
> principles and give it a shot.
>
> Primarily, I'd consider whether another function uses non-deterministic
> rows for its evaluation. I could be wrong, but I don't think any other
> function uses two different rows results within a single function
> evaluation. Even aggregates, such as string_agg, evaluate one row at a
> time which is a well-known behavior.
>
> A similar paradigm might be in general programming if a compiled program
> randomly 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 unexpected behavior for the SQL language and really any language, I
> think. Although, it is quite creative.
>
> It sounds like you've quickly isolated the line within the source. In an
> interest in learning more about the code, would you mind pointing my
> partner and I to the line for this bug?
>
https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/varlena.c
search string_agg
Regards
Pavel
>
> Thanks,
> Jeff
>
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> 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
> concatenating varying delimiter
>
> jeff@goaldriven.com writes:
> > Running the query below will show how the delimiter for the current
> > row is actually the subsequent rows delimiter.
>
> Hmm, well, the documentation for string_agg doesn't say what happens when
> the "delimiter" argument varies across rows; but a quick look at the code
> finds that the first-call delimiter isn't actually used at all, and on
> subsequent calls the delimiter is appended to the running result before the
> associated value is. Which seems to me to be at least as reasonable, and
> certainly a great deal easier to implement, as what you seem to have in
> mind. Can you offer a principled argument why it should be the other way
> around?
>
> regards, tom lane
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
>