Re: row_to_json(), NULL values, and AS

I wrote:
> So I'm now pretty well convinced that this is a good change and we
> should slip it into v11.

I wrote a test case and was about ready to commit this, when I started
wondering about the behavior for fdresult == FUNCDETAIL_MULTIPLE.
That is, suppose that the notation f(x) matches more than one candidate
function f, and there's also a column named f.  The old code would have
chosen the column interpretation, and so would the patch I posted
previously.  But I don't really see how we can square that behavior with
documenting that "we prefer the function interpretation for functional
notation".  I think you should get a "function is not unique" error in
such a case, not silently picking the column instead.  If it's the
column you want, write it like a column.

So the attached updated patch rearranges the error handling logic to
make that happen.

BTW, while trying to make a test case I was reminded that CREATE FUNCTION
tries to prevent this situation from arising:

regression=# create table t1 (f1 int);
CREATE TABLE
regression=# create function f1(t1) returns int as 'select 42' language sql;
ERROR:  "f1" is already an attribute of type t1

That's totally non-bulletproof, though, since you can still create the
situation by renaming, or by adding the conflicting column after you
create the function; not to mention Neil's original problem where the
conflicting function is declared to take record or some such.
Furthermore, this behavior itself creates a dump/reload hazard, since
once you've done one of those things pg_dump will produce output that
fails this check.

While I've not done anything about it here, I think we should just
remove that error check.  With this patch, functions and columns can
coexist reasonably peacefully, so we shouldn't need bogus hacks that
try to prevent it.

			regards, tom lane