Re: idea: custom log_line_prefix components besides application_name

> On May 9, 2017, at 9:48 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> David Fetter <david(at)fetter(dot)org> writes:
>> On Fri, May 05, 2017 at 02:20:26PM -0400, Robert Haas wrote:
>>> On Thu, May 4, 2017 at 10:59 AM, Chapman Flack <chap(at)anastigmatix(dot)net> wrote:
>>>> invalid input syntax for integer: "21' && 1=2)) Uni/**/ON
>>>> SEl/**/eCT 0x646665743166657274,0x646665743266657274,
>>>> 0x646665743366657274 -- "
>
>>> Now that is choice. I wonder what specific database system that's
>>> targeting...
>
>> It could well be targeting some class of pipeline to the database,
>> too, for example one that removes comments and/or un-escapes.
>
> Yeah. It's a bit hard to see a database's parser treating "Uni/**/ON"
> as UNION, but if some stack someplace had a keyword check ahead of
> a comment-stripping step, maybe that could do something useful.
>
>> It occurs to me that psql's habit of stripping out everything on a
>> line that follows a double dash might be vulnerable in this way, but
>> I wouldn't see such vulnerabilities as super easy to exploit, as psql
>> isn't usually exposed directly to input from the internet.
>
> I don't think that's a problem: while psql will remove "--" and everything
> following it until newline, it won't remove the newline. So there's still
> a token boundary there. If we tried to strip /*...*/ comments we'd have
> to be more careful.
>
> As far as the actual thread topic goes, I tend to agree with Robert's
> doubt that there's enough utility or consensus for this.

Consensus, no, but utility, yes.

In three tier architectures there is a general problem that the database
role used by the middle tier to connect to the database does not entail
information about the user who, such as a visitor to your website, made
the request of the middle tier. Chapman wants this information so he
can include it in the logs, but stored procedures that work in support
of the middle tier might want it for locale information, etc. As things
currently stand, there is no good way to get this passed all the way down
into the database stored procedure that needs it, given that you are
typically calling down through third party code that doesn't play along.

I expect proposals to address this have been made and rejected before.
Is there a word or phrase for this that I can use to search the archives
to read up on the issue?

Thanks,

Mark Dilger