From: | jwieck(at)debis(dot)com (Jan Wieck) |
---|---|
To: | maillist(at)candle(dot)pha(dot)pa(dot)us (Bruce Momjian) |
Cc: | jwieck(at)debis(dot)com, Inoue(at)tpf(dot)co(dot)jp, hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] What about LIMIT in SELECT ? |
Date: | 1998-10-20 17:22:40 |
Message-ID: | m0zVfUW-000EBPC@orion.SAPserv.Hamburg.dsh.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
>
> > >
> > > I agree. Another good thing is that the LIMIT thing will not require a
> > > dump/reload, so it is a good candidate for a minor release.
> >
> > That's wrong, sorry.
> >
> > The limit thing as I implemented it adds 2 new variables to
> > the Query structure. Rewrite rules are stored as querytrees
> > and in the existing pg_rewrite entries that would be missing.
>
> Oh, sorry. I forgot. That could be tough.
But it wouldn't hurt to add them now to have them in
place. The required out-, read- and copyfuncs are in
my patch too. This would prevent dump/load when we
later add the real LIMIT functionality. And it does
not change anything now.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-10-20 17:26:59 | Re: [HACKERS] What about LIMIT in SELECT ? |
Previous Message | Jan Wieck | 1998-10-20 17:12:19 | Re: [HACKERS] What about LIMIT in SELECT ? |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-10-20 17:26:59 | Re: [HACKERS] What about LIMIT in SELECT ? |
Previous Message | Bruce Momjian | 1998-10-20 17:22:30 | Re: [HACKERS] Bugfix for rule system |