Re: [BUGS] BUG #14545: Unable to retrieve parameter mode 'VARIADIC'
| От | Tom Lane | 
|---|---|
| Тема | Re: [BUGS] BUG #14545: Unable to retrieve parameter mode 'VARIADIC' | 
| Дата | |
| Msg-id | 1159.1487113853@sss.pgh.pa.us обсуждение исходный текст | 
| Ответ на | Re: [BUGS] BUG #14545: Unable to retrieve parameter mode 'VARIADIC' ("David G. Johnston" <david.g.johnston@gmail.com>) | 
| Ответы | Re: [BUGS] BUG #14545: Unable to retrieve parameter mode 'VARIADIC' | 
| Список | pgsql-bugs | 
"David G. Johnston" <david.g.johnston@gmail.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
-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
		
	В списке pgsql-bugs по дате отправления: