Limin Liu <[EMAIL PROTECTED]> writes:
> I just realized that INSERT allows us to have more syntax than the
> manual said. I wonder if we want to elimiate it or keep it with more
> documentation on the INSERT statment?
This will likely go away when we get around to upgrading INSERT to the
full SQ
On Wed, May 30, 2001 at 03:00:53PM -0300, Roberto Abalde wrote:
> Hi,
>
> I need to implement a cache for query plans as part of my BSc thesis. Does
> anybody know what happened to Karel Zak's patch?
>
Hi,
my patch is on my ftp and nobody works on it, but I mean it's good
begin for some ne
On Thu, May 31, 2001 at 10:07:36AM -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > What got me thinking about this is that I don't think my gram.y fix
> > would be accepted given the current review process,
>
> Not to put too fine a point on it: the project has advanced a l
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> Full implementation of R-Tree using GiST is available from
> http://www.sai.msu.su/~megera/postgres/gist/
Committed as a contrib module.
At some point we'll probably want to move this into the mainframe,
but I left it as a separate package for now.
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> We have implemented multi-key index support for GiST. Patch is available
> from
>http://www.sai.msu.su/~megera/postgres/gist/code/7.1.2/patch_multikeygist.7.1.2.gz
I have committed these changes, along with your leak patch of 5/30.
> 1. initdb is req
Lamar Owen <[EMAIL PROTECTED]> writes:
> Looking through the archives Ifind some details, such as the function
> locale_is_like_safe() , and I see other details -- but a concise picture of
> what one can expect operating in a non-locale_is_like_safe() (which
> currently includes ONLY the C an
Jan Wieck <[EMAIL PROTECTED]> writes:
> In the next couple of hours (at least tomorrow) I would be
> ready to commit the backend changes for table-/index-access
> statistics and current backend activity views.
> Should I apply the patches or provide a separate patch for
>
Kovacs Zoltan <[EMAIL PROTECTED]> writes:
> It means that the 21st line of the result is problematic, because writing
> 20 instead of 21 I got no problem.
I think not. The current implementation of LIMIT fetches one more row
than is really needed, IIRC.
regards, tom lane
On Thu, 31 May 2001, Tom Lane wrote:
> Indeed. You're looking at the aftermath of an "imperfect fix" to add
> foreign keys. With all due respect to Jan and Stephan, who did a great
> job adding the feature at all, there are still a lot of things that need
> to be fixed in that area. The troubl
Oleg Bartunov <[EMAIL PROTECTED]> writes:
> New version of contrib-intarray for postgresql version 7.1 and above
> is available from http://www.sai.msu.su/~megera/postgres/gist/
I'm going to be making commits later today that clean up the "char*
that should be Datum" ugliness in GiST. I think th
Helo,
On Thu, 31 May 2001 [EMAIL PROTECTED] wrote:
Questions:
> 1) What is the connection between small and big Dbs? (LAN/WAN)
> 2) Is there a consistent connection between systems?
> 3) Are you looking for synchronous (before the insert commits)
> or asynchronous
This is my first post/reply on this list, but I have been listening for a
while now (I mostly read the replication ones ;-). I am interested in
what developers/users are looking for in a replication/sync solution in
postgresql, and contributing to that effort.
>I'm trying to centralize data in
Bruce Momjian <[EMAIL PROTECTED]> writes:
> What got me thinking about this is that I don't think my gram.y fix
> would be accepted given the current review process,
Not to put too fine a point on it: the project has advanced a long way
since you did that code. Our standards *should* be higher t
Kovacs Zoltan <[EMAIL PROTECTED]> writes:
> Starting pg_dump, this error occured (there is no output dump,
> unfortunately). Getting closer, I got this:
> tir=# SELECT pg_get_viewdef(c.relname) AS definition FROM pg_class c
> offset 441 limit 1;
> ERROR: cache lookup for proc 4303134 failed
I t
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> The point was that in gist_tuple_replacekey (called from
> gistPageAddItem) key may be replaced by null value, but flag
> itup->t_info & INDEX_NULL_MASK is not set.
Ah. That's certainly a bug.
regards, tom lane
-
> What is the point of the macro
>
> #define ATTGET(itup, Rel, i, isnull ) ((char*)( \
> ( IndexTupleSize(itup) == sizeof(IndexTupleData) ) ? \
> *(isnull)=true, NULL \
> : \
> index_getattr(itup, i, (Rel)->r
16 matches
Mail list logo
