Re: generate_series woes - Mailing list pgsql-general

From Sam Mason
Subject Re: generate_series woes
Date
Msg-id 20080416175912.GL6870@frubble.xen.chris-lamb.co.uk
Whole thread Raw
In response to Re: generate_series woes  ("Merlin Moncure" <mmoncure@gmail.com>)
List pgsql-general
On Wed, Apr 16, 2008 at 09:01:10AM -0400, Merlin Moncure wrote:
> On Wed, Apr 16, 2008 at 8:37 AM, Volkan YAZICI <yazicivo@ttmail.com> wrote:
> > hubert depesz lubaczewski <depesz@depesz.com> writes:
> > > select i from generate_series(1,10) {hint:10} as i;
> > >
> > > i'm not proposiung syntax. i'm suggesting the functionality.
> >
> > I'm strongly declined for such non-SQL compliant solutions. I'd be
> > appreciated if hackers can solve the problem internally, without bugging
> > SQL syntax.
>
> maybe -- just an idle thought -- the 'ROWS' clause of create function
> could be expanded to take a simple expression based on the input
> parameters.

In computer science terms, I think you mean that you want something
known as dependant types.  Full dependant types are probably overkill
for PG, but some very limited form would be a fun project.  The idea,
in general, is to move code into the typesystem that is run during
typechecking and used to prove that your code is doing the right thing.
Within PG, this seems to naturally (from my naive viewpoint) extend to
the case of providing hints (proofs would be the normal use) to the
planner about what's going to happen when the code is run.

This seems to imply that types couldn't be stored as OIDs any more
(you'd be creating and destroying lots while planning the query) so
would probably change the structure of the code rather significantly.


  Sam

pgsql-general by date:

Previous
From: Ralph Smith
Date:
Subject: Re: I need to ecrypt one column to an output file
Next
From: Lincoln Yeoh
Date:
Subject: Re: Suggestion for psql command interpretation