Re: generate_series woes

From: Sam Mason <sam(at)samason(dot)me(dot)uk>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: generate_series woes
Date: 2008-04-16 17:59:12
Message-ID: 20080416175912.GL6870@frubble.xen.chris-lamb.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)ttmail(dot)com> wrote:
> > hubert depesz lubaczewski <depesz(at)depesz(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Lincoln Yeoh 2008-04-16 18:01:11 Re: Suggestion for psql command interpretation
Previous Message Ralph Smith 2008-04-16 17:58:32 Re: I need to ecrypt one column to an output file