Re: information schema parameter_default implementation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Amit Khandekar <amit(dot)khandekar(at)enterprisedb(dot)com>, Ali Dar <ali(dot)munir(dot)dar(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: information schema parameter_default implementation
Date: 2013-11-17 21:38:45
Message-ID: 18439.1384724325@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> [ 0001-Implement-information_schema.parameters.parameter_de.patch ]

I'm a bit confused as to where this column is coming from? There's
no such thing in SQL:2008 as far as I can see. If it's coming from
some not-yet-ratified draft, maybe we should wait for ratification.
It's impossible for a bystander to tell if this implementation conforms
to what the spec is expecting.

BTW, although SQL:2008 lacks this column in the parameters view, there
are about six columns it has that we don't: see the from_sql_xxx and
to_sql_xxx columns. Surely we should put those in (at least as dummy
columns) before trying to claim adherence to some even-newer spec draft.

As far as the code goes, I have no particular objections, modulo the
question about whether this patch is implementing spec-compatible
behavior. A small stylistic idea is that maybe the computation of
nth_inputarg should be moved down nearer where it's used. Really
that's just part of the calculation of nth_default, and it wouldn't
be unreasonable to stick it under the comment explaining why we're
doing that calculation like that.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2013-11-17 21:51:31 Re: additional json functionality
Previous Message David Johnston 2013-11-17 20:45:26 Re: additional json functionality