Re: BUG #14545: Unable to retrieve parameter mode 'VARIADIC'

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: Prajval Poojari <ppoojari(at)erwin(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14545: Unable to retrieve parameter mode 'VARIADIC'
Date: 2017-02-14 23:10:53
Message-ID: 1159.1487113853@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> I don't have access to an authoritative definition for what the allowed
> values for information_schema.parameters.parameter_mode are.​

SQL2011 saith

CONSTRAINT PARAMETER_MODE_CHECK
CHECK (
PARAMETER_MODE IN
( 'IN', 'OUT', 'INOUT' ) ),

> The fact that our "VARIADIC" mode maps to "IN" on the information schema is
> not accidental. The question is whether it is out-of-date.

Not that I can see. SQL doesn't have VARIADIC, so there's no way to
represent that a parameter is variadic within the information_schema.

This is generally true for all sorts of nonstandard features that PG has:
there's just no way to find out about them through the information_schema,
and there isn't going to be because making those views behave in
nonstandard ways would largely defeat the point of having them.

> Is there a reason you don't just use the PostgreSQL catalogs? Are you
> aware of other implementations of information schema that have this level
> of detail?

mysql, at least, feels free to extend the information_schema in
nonstandard ways. Our project policy is that they're doing it wrong.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2017-02-14 23:17:41 Re: BUG #14545: Unable to retrieve parameter mode 'VARIADIC'
Previous Message Prajval Poojari 2017-02-14 22:58:45 Re: BUG #14545: Unable to retrieve parameter mode 'VARIADIC'