Skip to content

P
Postgres FD Implementation
Commit c7caa796 authored by Bruce Momjian's avatar Bruce Momjian
Browse files
Options

Remove unused entries.

parent 7d21a98a
Hide whitespace changes
Inline Side-by-side
Showing with 24 additions and 4258 deletions
doc/FAQ
View file @ c7caa796
Frequently Asked Questions (FAQ) for PostgreSQL
Last updated: Mon Nov 12 02:38:47 EST 2001
Last updated: Tue Nov 27 14:16:49 EST 2001
Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
......@@ -28,6 +28,7 @@
1.12) How do I join the development team?
1.13) How do I submit a bug report?
1.14) How does PostgreSQL compare to other DBMS's?
1.14) How can I financially assist PostgreSQL?
User Client Questions
......@@ -358,6 +359,28 @@
We are free for all use, both commercial and non-commercial.
You can add our code to your product with no limitations,
except those outlined in our BSD-style license stated above.
1.13) How can I financially assist PostgreSQL?
PostgreSQL has had a first-class infrastructure since we started five
years ago. This is all thanks to Marc Fournier, who has created and
managed this infrastructure over the years.
Quality infrastructure is very important to an open-source project. It
prevents disruptions that can greatly delay forward movement of the
project.
Of course, this infrastructure is not cheap. There are a variety of
monthly and one-time expenses that are required to keep it going. If
you or your company has money it can donate to help fund this effort,
please go to the following URL and make a donation:
http://www.pgsql.com/pg_goodies
Although the web page mentions PostgreSQL, Inc, the "contributions"
item is solely to support the PostgreSQL project and does not fund any
specific company. If you prefer, you can also send a check to the
contact address.
_________________________________________________________________
User Client Questions
......
doc/TODO.detail/atttypmod deleted 100644 → 0
View file @ 7d21a98a
From tgl@sss.pgh.pa.us Sun May 23 12:32:34 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id MAA23977
for <maillist@candle.pha.pa.us>; Sun, 23 May 1999 12:32:33 -0400 (EDT)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA19926;
Sun, 23 May 1999 12:32:01 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] DEFAULT fixed
In-reply-to: Your message of Sat, 22 May 1999 21:12:19 -0400 (EDT)
<199905230112.VAA13489@candle.pha.pa.us>
Date: Sun, 23 May 1999 12:32:01 -0400
Message-ID: <19923.927477121@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Status: ROr
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> It might be best to just bite the bullet and make the parser carry
>> around both the type's OID and typmod at all times.
> I will try to add it, but I must not that there are some cases where I
> don't have access to the atttypmod of the result, so it may not be
> possible to do it in every case. Perhaps I should just leave this for
> post 6.5, because we don't have any other bug reports on it.
After further thought, I think this may be a more difficult and subtle
issue than we've realized. In the current state of the system, there
are many places where you have a value that you can only know the type
OID for, not atttypmod --- specifically, any intermediate expression
result. Barring reworking the entire function-call mechanism to pass
atttypmod around, that's not going to be possible to change.
The only context where you really know atttypmod is where you have
just fetched a value out of a table column or are about to store a
value into a table column. When storing, you need to be prepared to
coerce the given value to the right type if *either* type OID or
atttypmod is different --- but, in general, you don't know atttypmod
for the given value. (In the cases I know of, you can deduce it by
examining the value itself, but this requires type-specific knowledge.)
So on the whole I think this is something that has to be dealt with
at the point of storing data into a tuple. Maybe we need a new
fundamental operation for types that pay attention to atttypmod:
"make this value match the typmod of the target column, which is
thus-and-so". Trying to attack the problem from the source side by
propagating typmod all around the parser is probably doomed to failure,
because there will be many contexts where there's no way to know it.
Since you have a fix for the only symptom reported to date, I'm
inclined to agree that we should leave well enough alone for now;
there are other, bigger, problems that we need to address for 6.5.
But I think we'll have to come back to this issue later.
regards, tom lane
doc/TODO.detail/elog deleted 100644 → 0
View file @ 7d21a98a
This source diff could not be displayed because it is too large. You can view the blob instead.
doc/TODO.detail/tcl_arrays deleted 100644 → 0
View file @ 7d21a98a
From owner-pgsql-patches@hub.org Wed Oct 14 17:31:26 1998
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id RAA01594
for <maillist@candle.pha.pa.us>; Wed, 14 Oct 1998 17:31:24 -0400 (EDT)
Received: from hub.org (majordom@hub.org [209.47.148.200]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id RAA01745 for <maillist@candle.pha.pa.us>; Wed, 14 Oct 1998 17:12:28 -0400 (EDT)
Received: from localhost (majordom@localhost)
by hub.org (8.8.8/8.8.8) with SMTP id RAA06607;
Wed, 14 Oct 1998 17:10:43 -0400 (EDT)
(envelope-from owner-pgsql-patches@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Wed, 14 Oct 1998 17:10:27 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.8.8/8.8.8) id RAA06562
for pgsql-patches-outgoing; Wed, 14 Oct 1998 17:10:26 -0400 (EDT)
(envelope-from owner-pgsql-patches@postgreSQL.org)
X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-patches@postgreSQL.org using -f
Received: from mambo.cs.unitn.it (mambo.cs.unitn.it [193.205.199.204])
by hub.org (8.8.8/8.8.8) with SMTP id RAA06494
for <pgsql-patches@postgreSQL.org>; Wed, 14 Oct 1998 17:10:01 -0400 (EDT)
(envelope-from dz@cs.unitn.it)
Received: from nikita.wizard.net (ts-slip31.gelso.unitn.it [193.205.200.31]) by mambo.cs.unitn.it (8.6.12/8.6.12) with ESMTP id XAA20316 for <pgsql-patches@postgreSQL.org>; Wed, 14 Oct 1998 23:09:52 +0200
Received: (from dz@localhost) by nikita.wizard.net (8.8.5/8.6.9) id WAA00489 for pgsql-patches@postgreSQL.org; Wed, 14 Oct 1998 22:56:58 +0200
From: Massimo Dal Zotto <dz@cs.unitn.it>
Message-Id: <199810142056.WAA00489@nikita.wizard.net>
Subject: [PATCHES] TCL_ARRAYS
To: pgsql-patches@postgreSQL.org (Pgsql Patches)
Date: Wed, 14 Oct 1998 22:56:58 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL24 ME4]
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-pgsql-patches@postgreSQL.org
Precedence: bulk
Status: RO
Hi,
I have written this patch which fixes some problems with TCL_ARRAYS.
The new array code uses a temporary buffer and is disabled by default
because it depends on contrib/string-io which most of you don't use.
This raises once again the problem of backslashes/escapes and various
ambiguities in pgsql output. I hope this will be solved in 6.5.
*** src/interfaces/libpgtcl/pgtclCmds.c.orig Mon Sep 21 09:00:19 1998
--- src/interfaces/libpgtcl/pgtclCmds.c Wed Oct 14 15:32:21 1998
***************
*** 602,616 ****
{
for (i = 0; i < PQnfields(result); i++)
{
sprintf(nameBuffer, "%d,%.200s", tupno, PQfname(result, i));
if (Tcl_SetVar2(interp, arrVar, nameBuffer,
! #ifdef TCL_ARRAYS
! tcl_value(PQgetvalue(result, tupno, i)),
#else
PQgetvalue(result, tupno, i),
- #endif
TCL_LEAVE_ERR_MSG) == NULL)
return TCL_ERROR;
}
}
Tcl_AppendResult(interp, arrVar, 0);
--- 602,624 ----
{
for (i = 0; i < PQnfields(result); i++)
{
+ #ifdef TCL_ARRAYS
+ char *buff = strdup(PQgetvalue(result, tupno, i));
sprintf(nameBuffer, "%d,%.200s", tupno, PQfname(result, i));
if (Tcl_SetVar2(interp, arrVar, nameBuffer,
! tcl_value(buff),
! TCL_LEAVE_ERR_MSG) == NULL) {
! free(buff);
! return TCL_ERROR;
! }
! free(buff);
#else
+ sprintf(nameBuffer, "%d,%.200s", tupno, PQfname(result, i));
+ if (Tcl_SetVar2(interp, arrVar, nameBuffer,
PQgetvalue(result, tupno, i),
TCL_LEAVE_ERR_MSG) == NULL)
return TCL_ERROR;
+ #endif
}
}
Tcl_AppendResult(interp, arrVar, 0);
***************
*** 636,643 ****
*/
for (tupno = 0; tupno < PQntuples(result); tupno++)
{
const char *field0 = PQgetvalue(result, tupno, 0);
! char * workspace = malloc(strlen(field0) + strlen(appendstr) + 210);
for (i = 1; i < PQnfields(result); i++)
{
--- 644,674 ----
*/
for (tupno = 0; tupno < PQntuples(result); tupno++)
{
+ #ifdef TCL_ARRAYS
+ char *buff = strdup(PQgetvalue(result, tupno, 0));
+ const char *field0 = tcl_value(buff);
+ char *workspace = malloc(strlen(field0) + 210 + strlen(appendstr));
+
+ for (i = 1; i < PQnfields(result); i++)
+ {
+ free(buff);
+ buff = strdup(PQgetvalue(result, tupno, i));
+ sprintf(workspace, "%s,%.200s%s", field0, PQfname(result,i),
+ appendstr);
+ if (Tcl_SetVar2(interp, arrVar, workspace,
+ tcl_value(buff),
+ TCL_LEAVE_ERR_MSG) == NULL)
+ {
+ free(buff);
+ free(workspace);
+ return TCL_ERROR;
+ }
+ }
+ free(buff);
+ free(workspace);
+ #else
const char *field0 = PQgetvalue(result, tupno, 0);
! char *workspace = malloc(strlen(field0) + 210 + strlen(appendstr));
for (i = 1; i < PQnfields(result); i++)
{
***************
*** 652,657 ****
--- 683,689 ----
}
}
free(workspace);
+ #endif
}
Tcl_AppendResult(interp, arrVar, 0);
return TCL_OK;
***************
*** 669,676 ****
--- 701,716 ----
Tcl_AppendResult(interp, "argument to getTuple cannot exceed number of tuples - 1", 0);
return TCL_ERROR;
}
+ #ifdef TCL_ARRAYS
+ for (i = 0; i < PQnfields(result); i++) {
+ char *buff = strdup(PQgetvalue(result, tupno, i));
+ Tcl_AppendElement(interp, tcl_value(buff));
+ free(buff);
+ }
+ #else
for (i = 0; i < PQnfields(result); i++)
Tcl_AppendElement(interp, PQgetvalue(result, tupno, i));
+ #endif
return TCL_OK;
}
else if (strcmp(opt, "-tupleArray") == 0)
***************
*** 688,697 ****
--- 728,748 ----
}
for (i = 0; i < PQnfields(result); i++)
{
+ #ifdef TCL_ARRAYS
+ char *buff = strdup(PQgetvalue(result, tupno, i));
+ if (Tcl_SetVar2(interp, argv[4], PQfname(result, i),
+ tcl_value(buff),
+ TCL_LEAVE_ERR_MSG) == NULL) {
+ free(buff);
+ return TCL_ERROR;
+ }
+ free(buff);
+ #else
if (Tcl_SetVar2(interp, argv[4], PQfname(result, i),
PQgetvalue(result, tupno, i),
TCL_LEAVE_ERR_MSG) == NULL)
return TCL_ERROR;
+ #endif
}
return TCL_OK;
}
***************
*** 1303,1310 ****
sprintf(buffer, "%d", tupno);
Tcl_SetVar2(interp, argv[3], ".tupno", buffer, 0);
for (column = 0; column < ncols; column++)
! Tcl_SetVar2(interp, argv[3], info[column].cname, PQgetvalue(result, tupno, column), 0);
Tcl_SetVar2(interp, argv[3], ".command", "update", 0);
--- 1354,1371 ----
sprintf(buffer, "%d", tupno);
Tcl_SetVar2(interp, argv[3], ".tupno", buffer, 0);
+ #ifdef TCL_ARRAYS
+ for (column = 0; column < ncols; column++) {
+ char *buff = strdup(PQgetvalue(result, tupno, column));
+ Tcl_SetVar2(interp, argv[3], info[column].cname,
+ tcl_value(buff), 0);
+ free(buff);
+ }
+ #else
for (column = 0; column < ncols; column++)
! Tcl_SetVar2(interp, argv[3], info[column].cname,
! PQgetvalue(result, tupno, column), 0);
! #endif
Tcl_SetVar2(interp, argv[3], ".command", "update", 0);
*** src/include/config.h.in.orig Wed Aug 26 09:01:16 1998
--- src/include/config.h.in Wed Oct 14 22:44:00 1998
***************
*** 312,318 ****
* of postgres C-like arrays, for example {{"a1" "a2"} {"b1" "b2"}} instead
* of {{"a1","a2"},{"b1","b2"}}.
*/
! #define TCL_ARRAYS
/*
* The following flag allows limiting the number of rows returned by a query.
--- 312,318 ----
* of postgres C-like arrays, for example {{"a1" "a2"} {"b1" "b2"}} instead
* of {{"a1","a2"},{"b1","b2"}}.
*/
! /* #define TCL_ARRAYS */
/*
* The following flag allows limiting the number of rows returned by a query.
--
Massimo Dal Zotto
+----------------------------------------------------------------------+
| Massimo Dal Zotto email: dz@cs.unitn.it |
| Via Marconi, 141 phone: ++39-461-534251 |
| 38057 Pergine Valsugana (TN) www: http://www.cs.unitn.it/~dz/ |
| Italy pgp: finger dz@tango.cs.unitn.it |
+----------------------------------------------------------------------+
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment