sharpetronics/PostgreSQL
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-04 00:02:37 -04:00
Code Issues Projects Releases Wiki Activity

Remove unused TODO.detail files.

Browse Source
This commit is contained in:
Bruce Momjian 2000-07-04 05:17:03 +00:00
parent c229f7d2ab
commit e799f19f0c
10 changed files with 0 additions and 8582 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

317
doc/TODO.detail/alpha
View File

@ -1,317 +0,0 @@
From owner-pgsql-hackers@hub.org Fri May 14 16:00:46 1999
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 QAA02173
for <maillist@candle.pha.pa.us>; Fri, 14 May 1999 16:00:44 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id QAA02824 for <maillist@candle.pha.pa.us>; Fri, 14 May 1999 16:00:45 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA47798;
Fri, 14 May 1999 15:57:54 -0400 (EDT)
(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Fri, 14 May 1999 15:54:30 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id PAA47191
for pgsql-hackers-outgoing; Fri, 14 May 1999 15:54:28 -0400 (EDT)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
Received: from thelab.hub.org (nat194.147.mpoweredpc.net [142.177.194.147])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA46457
for <pgsql-hackers@postgresql.org>; Fri, 14 May 1999 15:49:35 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA16128;
Fri, 14 May 1999 16:49:44 -0300 (ADT)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Fri, 14 May 1999 16:49:44 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgreSQL.org
cc: Jack Howarth <howarth@nitro.med.uc.edu>
Subject: [HACKERS] postgresql bug report (fwd)
Message-ID: <Pine.BSF.4.05.9905141649150.47191-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: ROr
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
---------- Forwarded message ----------
Date: Fri, 14 May 1999 14:50:58 -0400
From: Jack Howarth <howarth@nitro.med.uc.edu>
To: scrappy@hub.org
Subject: postgresql bug report
Marc,
In porting the RedHat 6.0 srpm set for a linuxppc release we
believe a bug has been identified in
the postgresql source for 6.5-0.beta1. Our development tools are as
follows...
glibc 2.1.1 pre 2
linux 2.2.6
egcs 1.1.2
the latest binutils snapshot
The bug that we see is that when egcs compiles postgresql at -O1 or
higher (-O0 is fine),
postgresql creates incorrectly formed databases such that when the user
does a destroydb
the database can not be destroyed. Franz Sirl has identified the problem
as follows...
it seems that this problem is a type casting/promotion bug in the
source. The
routine _bt_checkkeys() in backend/access/nbtree/nbtutils.c calls
int2eq() in
backend/utils/adt/int.c via a function pointer
*fmgr_faddr(&key[0].sk_func). As
the type information for int2eq is lost via the function pointer,
the compiler
passes 2 ints, but int2eq expects 2 (preformatted in a 32bit reg)
int16's.
This particular bug goes away, if I for example change int2eq to:
bool
int2eq(int32 arg1, int32 arg2)
{
return (int16)arg1 == (int16)arg2;
}
This moves away the type casting/promotion "work" from caller to the
callee and
is probably the right thing to do for functions used via function
pointers.
...because of the large number of changes required to do this, Franz
thought we should
pass this on to the postgresql maintainers for correction. Please feel
free to contact
Franz Sirl (Franz.Sirl-kernel@lauterbach.com) if you have any questions
on this bug
report.
--
------------------------------------------------------------------------------
Jack W. Howarth, Ph.D. 231 Bethesda Avenue
NMR Facility Director Cincinnati, Ohio 45267-0524
Dept. of Molecular Genetics phone: (513) 558-4420
Univ. of Cincinnati College of Medicine fax: (513) 558-8474
From gatgul@voicenet.com Thu Jul 22 21:58:42 1999
Received: from voicenet.com (mail12.voicenet.com [207.103.0.6])
by candle.pha.pa.us (8.9.0/8.9.0) with SMTP id VAA20482
for <maillist@candle.pha.pa.us>; Thu, 22 Jul 1999 21:58:39 -0400 (EDT)
Received: (qmail 17312 invoked from network); 23 Jul 1999 01:58:33 -0000
Received: from dialpool1745.voicenet.com (HELO voicenet.com) (209.71.57.45)
by mail12.voicenet.com with SMTP; 23 Jul 1999 01:58:33 -0000
Sender: gat
Message-ID: <3797CB70.7554322B@voicenet.com>
Date: Thu, 22 Jul 1999 21:54:56 -0400
From: Uncle George <gatgul@voicenet.com>
Organization: Big Endian
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686)
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [PORTS] RedHat6.0 & Alpha
References: <199907221830.OAA06403@candle.pha.pa.us>
Content-Type: multipart/mixed; boundary="------------8DF2D5BA86BB12328C66DD16"
Status: ROr
This is a multi-part message in MIME format.
--------------8DF2D5BA86BB12328C66DD16
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
>
> Can I now put back optimization to -O2 on alpha? Please send me your
> other diffs.
>
--------------8DF2D5BA86BB12328C66DD16
Content-Type: application/octet-stream; name="g.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="g.gz"
H4sICMDHlzcAA2cA1D1rc9tGkp/pXzFyKjFJQyIwAElQkrWl2MpGV36kJMWX2r09FkiCFNYg
SAOgYieb++3XPTN4cgACfNiyatcBgUFPv6enZ6Zx0gn8cWdkjT/Y3qRjjcd2EHTureCe/TNd
eeOT8ZN2u01OKjQ8WfjOrHF3vyL/tXIJpYSqp4Z5Sk2iDQaDJ8fHx5XApCFo6intnXY1DqGd
/WOIUU3Ru4T9JOQ7xxu7q4lNnqZAn9w/hUfwv5XjhTp9ckTwLlzTJvyj9cgH+3MLHv8JTxq+
Ha58jzR52xb5P3h4Bg//koMwREMZDPmryAWOM1wdb4HzKytczctxbnLCWtioFPlCWABCQJPD
kElC63YVrafFspjYU8ezyS8312+uaKPR0FTD7Jq6BJfxveU38Z8EFUIa0ALecm0Pu2/wFxqN
+zPGwqiziIk1O8sRXtablNSeDr0PIlIb9+QFUdmLAACuA+cPezFlJDHmNTpt8nLhPdh+SBid
4YJAD/bM9km7g3xHCPekzQnQyP+SJiBHjskz8oxDuCffvxDknXGqIllFHBE4CY4cBCf+dh3M
pAbvjULftvE/48V8afl2mZORNN7W0UhAZaBop2rv1KAlzqanGOq6s1mFjht0RivHDR0viG03
0rpRiIY7ni+Fv7EUwi9GayYsLLhpAYNHabvLwDIELPA7HBZcrMFiINYgMPfDqFhzP5Wp4MYD
PfOLYiqEG0JMxOUGmipCjgDC5TqFMrkZA6WnR3KT9U6NvHhkLG1GlFktKXMjUmhePjJZMyIi
gBK+oKQ43kJSxXhvZJvgPse7kHMZ9OuIIgIvoULqPTWqaFrsPfMoWKMgdOY2InE5ChbuKrTv
4Dfikvk9Snz3lGSaXgc/2tOFbzfhlVELmzUitI815rNsN7BJ4WsjBTjV4l4VcaWxtZTgyvk0
iTk2Efg9J40sGeBVsRUZ4QWTwqEIkDKfwjBBB4XGgB4eyWFDAnTP/puwes3EcaQ0W1ybxXWk
Box/1FA0XS3U4ag7ubrV7DDr9H37d98J7ei/byzPWUoHGnnDokFmUDTIyME0/tuecAgaDjBG
91TvFQ8wvcFA6asGlw52wW/EwWID/1D20fWf0UWj7S0m9i+hD1o1Xiw/vxv92x6HTQ9Y81y0
cKbN6+CyGTVUyHsQrdAu/Gs28Ua7RaIWreOLB8t37QfocbUEwOG9EwxTt86id/8SF3kZ8DHF
moQdFLSU+/kmtfmeB5B+Vx2c6uapOijmuG6khnTSbjQQyGKFweAxMJLFRwF59ukZxkdPPz1l
rTrwLzOMNiixeEE4/PF9rLr4oIHNfTtYuSHwj1sVcHhpue5i3KRMcRlNHA8h5p3w4Ba0DR5y
jVT63TR/lj4Qao1cm3VojUPbPzk5kaDjTFJcKUKGadDLxXxueZPrSWNMz4TaY68pbtTsVfCg
Rq8y2s2eonWNhPh9/nW4JxwtFq6Qnf0RmWUSy59pLGpgl3QtboDH5MUL9iw13KYAeXZ1QEdl
gNywBBDJTjzRJSPA8/TPIrhlCBbBfVEB8GwLhC+qwN0C4YtChPGmALx0q4vqeQmcuVMdznEZ
nFUNhNolgCbOQ3VAnSLWO5PdjIIhhP5EWHLsUA5uySKeYVjH12toM9paEfLxr2K7rg32aDNY
NywFu5udbwO5oqVvAbqirW8DuaK11xbgc7n8srZfG+rxZqirLZBtbwSLfqE22E65DjMvsTeD
Y8jmTBx/E61rKlpfzc2cQvtTGIdfQ/yVOKxYY/B2LvzgiiTiMRGGvb+8+fnVze0/QOgaz63B
ndvrf1w1ecsWNE23OUPK2vjaq8u7y6gRtsLec8m4pGsxMxPkZGdmEnISzn49ehK5lVBVNC2Y
WKE8w5hvssPUgwPITfZ0/VQvySZq3YGi9Xrp4Nq3XcwnsLg/FfaH9zbLzfqe5RKY4c+tEKcB
FhHtSRBCfDx7shYOJ/CaN7Zrhc4DT0LgzdLgGACuxtDJvBGGyhM2ucMW4RyE8UMYRkl4JKCf
jtMPSADXwzDOqqwRhHqSvtkinJat6JMKbKAp2sCMPQD5/d6BMU5tcZ0MQuh6TB4WziTBnIbz
ddYrJO4ffGY4j0Vx9+bdq19fv2vyRuH8+CKcDz/bFkzWda2r91RV5YYkbThfeAqh3QHd0Gxi
fVYgJDJYKybIAVWoGq+mbEmYnKrKknpOvhIHZKLWu31F7xnZHCWieru0PNSUhBFD/CeA21l2
iKeJaFMvpxSRrzsxArkaNoCGUKzpALmAhZnNPm7CgtsJ3pYLIDK5NRngg7NtUJUy0DQVfZDJ
HMw/hMwHPFgucw6+DU4zACfA0Ikekd+d8J6Ad10u4Ba4Do3ALJ2ENHYOLNUpWgMDUmCzCeNQ
y2WMwySGy94HBfdx3Lr88fbu+s3Vm+u3TXwZ2keUhoBQqsHlb1GDmGERRjEhQoRgWqBmaR/5
BfggUtBxLDSh8mQ0AH3BmoUUL1gc9GV4I9MZQzMVg2Z0BlmydFkSjI/4fCwBECubLKakKTLw
SMlz1OBEzpxJaWKASRzeup5kXVSiJ5hiD1mw+PLXm5urt3dDQSZPmzL+/d0OX6583/bCO9/y
AmscOgvvFtmG0JpJjs+gumJARJDShQPRV1P+Z+teOqUPe+OBVOZ6XzEMIy/zuVONJ8exO9vA
FJglfSWhG4ZipHMPhyNwf1LnY/FhBd/tKUayKot8EWQjaypxJv6R4oyIVdJkAYNiyNVHiH0R
zwFRKSCmHz3gQzbZ/SX4sP0IsV/dKGOPVG36XcUwaVptHC89nEb8wnThdIoUM2IIztCIE8AQ
lMxGcOCMGAY3gEEJrJymKJnhNn49oy7RzeML5P4qQKLuhtdv765u3l++HsL/r1+RH34gIabl
rt+y31m2RWkKIaeZ3QwVkoAFGqx/qv9qARAx9oqGrqyh9q+WiO8NE5zsoJfWsQMxTShTKbfW
VAwVK61Xj5KPUmU0B8DX1HJtV9WVrhpvwspYH4nhgkdvlvKnDiMyBCf2vUaDjP54K4GUuq42
ULrJLrfU9H5mS5QGTH7GQlkfdAUmDwuf2B9XQB1M9FNRq8jaCUj2x9wksmhYPkq7nEjmN1ev
UebkP/8h3IXkHmR4o56lEoEcTihJJwrEPPurIXZUipibT+V8OcTOy/CafT28Lkr59fUEeV4q
yNnXQ+wihxj3XbqhdAeqJJu3V3MXabw48MhRmc1JyGnGtkB3Ln9Rkw2yjvIAy7zDo6XjqAYd
8drfI6TjvDoZs0dMxkUNaTxirTqvoVWzR0zHRSkd0jjIhKDO1DKbxPhfPDPPe7so0nLBUXzM
hXp5Jx/PILJJ2nhRjbHLKYgAGR9aOAg0Qxlf+BTTpIZiZvNOOxEggvyC/D6P5g9GkFRCmqmY
2cQh/4OxqAqN4M6/vpAMVTENc11I29Pw+OSkgyUZW1oSjFVfX0jdnmL2jO0sSULA45OQAZbU
lVhSFQJnj0FCfaqYprqdhCQEPD4J9cCG+hIbarAwvJIiPgZ3Z4KiZVNSeyDj8UmrD2SaEnsS
c6WqtM4egcgGqqEMNEkYsTstX1VuRXt6pu7CCjdsHBJtdtg5JCDkDiJqvVPaL9k6pKuKpqe2
DpGVBxBZknbi4Gaa0QqT7QGxfJuslpjHnZxkhHZ8PPn3nGi0o/U6g54Q1xH5DplJ+HHaSdN1
vNUnTJPGd4ZDy13eW8Nhi7D7R9GDX9/eXv50Nfzp9bvLu1sUZHQmN/MA7wP9zjTKOkSUxEr1
2CjBR2olcqT239VgPM3kUB0jXEyyxzrAcMA+DOKt5iPb5zujmF6Y4lZsTexuz0CDQjDieAU0
iu1ftGg0CvbmNUWD+PCHOBgsbmNquJWsXjL8e5nhdK/4c8P3irF/zvad6LQBgMRGQDwH5u1A
l3xUhcCun1mGdmgBnbQenVTISesdUk69PuCfXeHZJ/4V5aT1UnLCI6H7ltNAGygD8Iw5e5ru
pI/sLCIDU2RPWAugVE6okxJ6dJqT04BqykBfs6e94S+VUxr7mvZUhS6pnHSIFQyatycpnZX1
kdNJhZxk9rQ/Oel9wH/NnvaGf0U5VbanKnQVRSAAekOUw1rsEOOw9/MRjnmqdUtOwqpKdms0
MnrtPGRwv/DZTuKnwCbJmUjxklCXoPBMZCx33m1mnXyHbrmUN3Qro56qXYVqefqNNUSYlyjF
w0gOYbqlaGR0Knc+VKOtswYWDLGCYDW3gQHOzFOIpkKINnPCQCHP/kd9JsqGuOHCarqK2JrP
15glu/UFwyNKsyzfmlLO8S9JqfCglQiWippSheqpGaI4T+Z4ib9wjKg2RfoURu5ofHQ6IjnH
ovXEuODQqBxF+n2Mj8VZrtufb+6Gb67f8kS67S5mzaubm3c3CnnK3z8lz76fPCNjaxXYAXd6
K29i++Blfn+qcLhnGaAXAujlb3z2yOlMHRaQ0yk5bVKLzvj9eC6ZUJ4a7+BnesfJl2GDVPz6
QKFGt+hUEXYRnyrKK4DsGA5jtaEBzH7R0Z4EZsWjPVK8TVWhZuyh/kKbwXeHCL3ZisWb7tWI
KcmrYiElJiiNGSfF6/SyA2263lMMc5DzvrgKnl4G5zulxOE/PEQWa3WS8jD4+VVBblRYpv6x
bgTFj3VXBVV4sBtBuWEdUOdlkGohdV6G1KwWUhdlkGohdVGCFOXyE4YX1fLZSn6Uy68qqDL5
UTesA6pEftSthVSZ/OisFlIl8qOzWkiVym+PBkj3aIF0fyZI92iDdH9GSPdohQbdoxule/Sj
dH+OlO7Rk9L9uVK6qxQTcB/sz1PHD8LYpbY3mXe7QJodvtlW103FGGi5qcO2w3T1A+RY9ix1
gpz/LB606wM+qgB4Q9UGOeDzCnC3Qfi8AsIbKjbIAV9UgLsNwhebEaa1dALLHKZ0gv8sDgTq
Az6qALiWTkSAzyvA3Qbh8woI19KJCPBFBbjbIHxRAeGDOQp6ME9BD+Uq6MF8BT2Us6AH8xZG
PXdRZwip5y/qjCH1HEaNQaSex6gzitRzGTWGkXo+Y6NmbA57ijtop1Vj3R112tKkhTHQlV5X
yyUt/kmNf02ch3RExKB3sqGQEyXhgBOreRLx5VE7tjBvtlbHE1/jpcyqBoqyYmYxKH58qSoo
WT2zBNSqFlqykmYxLFHTrCqstapmaViONy7mMtwSdZ8wVSlNdoIv43LiofNmOcWvcTlVnVzL
5BSD4nKqCkompwTUqhZaMjnFsIScqsKSySmGJeQk53IiJ1ya0+Sipnu0DLpH06D7tA26V+Og
e/QldI/OhO7Tm9BdOdbJufk57vbIuXm4V+zo5/H+oUoIfF8m/3m8x6WSzZXC2idiBt0VWJ7N
U2ucZ/ORlL3QULrqhrfyuxRSa1BadJhFrFCq4gj3oAvDu5FLdmw3vOfWyNZCm/JRvn6U9Lwg
SMqN+fUBH1cBXKuQYQS5XQFyvVqGEeROBcg46mwS0vPnxWP8JhnDcFUeIdSfPT8viFZz8UJ9
wMdVANeScQS5XQFyPRlHkDsVIG+UMbwukXEmrDiIKdKD2SI9nDHSA1pjPYOo4/TqWUQdr1fT
JOq4vZo2sYnTewlj6qPzfQWdqgc5Mv7vi40/G+IcBGmjJtabQO8U/uT823r0E+9GZTjktudU
CY2kWwe7PaWX1G6UsF+EZvn9NOxW/dCs1x1Af2Zuu02+Pykv0t3FOz7TzGBf7dmJGT1AbiD5
+FE8ELkA0PYrRu/Rpib2jPyNm+dp2Qw6mOOhn3rwzzfDj/UsQb9CiF8Z/Rh8Cv3K8EvQZ/rS
10Ek+e1ZEpFUtOLCxRHEIP3wtEJYEtG7Rd/nW/adF2WNrqUJ3qjr6OFpBa+5BdnSfHiFvos2
SXuieNOGvdhJsx02ZCdA8iWrjdNuyddy+OeccmVxRV1gARLrAmfLezlYeRe4QNrhH8t8kWDx
hSl4FG+G/86ZTuwp+fX2avjLu9vr34Z4Tg+dXfImtP+EZR6wNdavEifBOm1ylHuPD0zxq4DL
iISjM94YD5kt3Al53z92grnYTZh8tsrIFt5dp5NryCEJZLUih2GD7VXm1y3W4dkhSJeKXO8r
mtFLibwQfVal6I8lrj29/fX16xbi3wg/AeruYmyxg6FNQQRuuf4BL1M1yOC/fyavzOYl7f/i
5GcPEnI8E5HthCf0RjbhlrTJ4SPdMKupCtXik0uiPmOmkCcByVOhXs28FqF+hX/EnshhxZix
jjVDq9EI7HEUJYB4HyzXwaOSChmxT8KR2cLxZmSxCrF8pG95MxC/R4IFGOjcxqMqgVAXxpyk
7DZGGgNVY3WmUncvwNnopviaLSdMMH5vhDH1T4P5SjRKdwhrfUWnqeOC5O/Og+3hgaCM7xPj
BRrblTdzneCeb1V+AFwcwA3wZAddgYona2caIieN5xrWPGocRcqq23Mehn+wH5PFauQC86bA
vSRo5RSkyo4emgLhK+Nt+WsUoYdL3ywr37+BQKnIerqiZ+omyD6dCPwgoJ82L3EGDzQsf2lN
WZkz9PrJN8fE+q70A4xrxK0VmkVYsQwvg8D2w9y3HN+jejP3p/EDXJua0dT5Nb1nALV6Kl18
QGqFaNeKPcmkjBMbbMnhE16Ijh/E2C8XpDrQHyi6KRnL3r67G8I48aqI0EtkySOQqkkVPdnx
WBf/b0dOA1Mx1PhQDB7H4o5kOHU8J7Sbrbxe5p5nv7jKn8VyiYP4qG5yURVZgmf/063evru9
u7xJKhSvP796m8DgXyVtSLBH1NmijqorRlJRoz6dr3J1M2R0r/vVuNju4+CETAMMzVAMqkmq
g++hGKWAZH/cphp4jj/rBThlhYh/unx9e3WWBSSvBk41xcieDz8E3UJv9lD9+3DskKoF7QN7
8qm9LHlefvh9DGLFE2VGN5fyWcP7mxWLoQJ5/VKxuPkg9jGIpQvW1st/A20N729WLF2dkVcm
ltljFEv2kwhFeH+zYmHk5VPyOa17jE7MBGsZbLCWb9iJweTASJ1olmrdYxTLoKd01Q3W8u2K
pdtVlW43VfGHvOQ1IZLPnixY+oHls+OQB4jk9PCvpEVxZ9SwfIaQfnl9NfDoF/wil+1Hs5n8
Zy9FAZYISKsl6ud1ewOl209VQNgPJWKZouYcwDo7DKGFKw6rue07402LG1GrXdY2Ihjp1zXt
VDVO9ZKCMxp4Za2fqljE5MT/Ylm85bAxtcWvho4nSogEoc9zmZPVfP45WiQMPy/ni0msWOL9
95bfYN/yOUvdZGu54nuMApdEU3bDRUz3a+Mi5RO4G6rGfMIPyYTDB8tv/sCg8Ll/YLN7w6m/
mA8BmybDKNUCc7vWcul+HnKsxNtKhGSkhoAG6Nvc+mAPufZlupn6tp3tm3FPYCi4tW8MxYLe
jojKVdDQFa3XVaVKuMufRGlw1XMoNEesbqe/Z5RVhKy6pBKxcXI2nC8j3eVEaFLtPSQRXMsf
YkcYEwWCeZBod0WiivzMwpls8GasxQ6ejL2fK5sFb9MyL9bvKtpAkwcxC/xSNrKs+c6ZFOxl
YFkoaIiJ4JWH1Y/siUJGq5DxGu/ye6IEUrJ1muJhKBXzQJa/6Qy+/RF6yGypEAjtioS2CQlR
KIYpqmCVUK3NrMrvB9gOy9R+gDVkN55S44xLb1LYB+NyJ9oYSrlTinI2FikueDq0oQ3mEbfa
wURiGJnBXj+l/dLBHsu8pYtIApNtVtSJ/G5DdBMEOA7BZAa4zL+8F9jjhcc4DR4DBtbpwocf
vvUZBt2TJEsbr3yNlniZDMiS0MAKw9yInFvpSn2X2k+term2dxbXqkt/L+ALECGmDumowsr5
25gs/Ay9bAGvjCypS2ML++m1VmiKqowksaLt9yRY2mNn6oBiO6DOLbJ0V0HyafnR59AOToro
y4gIy+TZXk2J+PCKIjYhmOlNCAfElTPfzTEfe3tB3Bps57jL+E41qlCq7o/vl6hqd6CSfCIz
FCQlt9sPazJIe3dU1Lm1bEKrH395+fPlzbvrV4pgTOYWuEUEkPJXYqOCAQTR/QmnEkFCULsS
JPxxni6p4HSNVdpLBBfNM5n2wCRTIKq1JIqGFxElXBjjsr0GnLO6Dj0OJDPbuj1ybpX3KKNZ
p7qi6+ohXboYanbz6XmHFy3s0i6grx/SmZejv6Uvl5AjlY6pKbpppjQy2JdfFGTlnXhQ4sWL
ZGAaij5Iu4fDISnG0SDL70bA/fck2IHX/CPj2uHcdkTMNn4b+oidmoCTvVnguvm6X/dwrltO
VDXfXYWoAvddEtZCU2tzAM1b7RZAcxiZAFrFbBlM4QsDaO6wMtkycne/mINzer0YfwAWhPiy
eazRY02N2R7X6WRFPIPVCDMv/CZ+6sGbRYo0jy4SK05V76zsRveGlTDYeXzl5VwlFunGx8x+
GUabEOYScbyxu5rYHWs8toOgc28F9yf3KalLn1eWt/TtfF60d6rSYknTHoSB/XgvDtBkgwHg
XmiC4CYwJoXRl0wX7AMwCrkO7bnIHZPQiZNkMDfFV6Yrb3wy5lNQAW7FmYhP8RCCOCzywf7c
OitqZDTFb96KyFuZCArPAhW3YoXSjaheOoJblrU0oy8VlLXEWTrOzIt7hRYma9IupjIZM4rh
sFq3/9/dtTS3bQPhc/MrlFNcj/KQLCl2eu5ML31M07uGth7mVCI1Ip1M8+sLYPHGLoiVHdvx
xSNL3y6XiwWIBRcfdEmt7ssi7Gl8U+3XZ3+IPyKOBbJxxWWmoXXneZyGht400NA+6MW289BN
PkxDh8MCPAau7+pdXzcdOu7EEPbQEyuI1zPnn6YLevSZLcYip/YKNkVowYIPDN36vnWi4s9v
b259b5vvqqPjw1eIWEW9cjNkREG98uT93+UinQIBz9OlW169hPU5DAtUpGVYoBotxDL0bhl6
t8N61ZcSCxwuZVjgaCnE3jEUa46VgruT670UdBToVZME1WVhiqC2kHr64FuV1Bq6c1DqjY61
PBADieBaEQPo+JOnmyQRWMcnWoTmSX4xCbl0UXzb+Rin5dKpiUFgjETNZlZR3Rzu+iVMiFCN
M++sifOqWapJcqq2VgQXA/cYHFsRtqxUkZyJEELEt+mxB0kT1Ri3fuJORzefa+4aY7dPbt3o
mhG6VCjWWdp4DE0zGmNomrMYRbN008TDKJqje0pTsWNomm0dQ9OE6iiapZvmRUfRLN28QMkx
mKNwVqjkiMhROCtYcnziWGxNeV0owwqOwnmdKEPujcJ53SjD0R3DCzi408E25oREETRlGwqn
WdlwOE28huIz3GooPqRjTB8mMd0iiqCZFVE4zZ6Iw2mGRBSfYUFE8SHTIealHJMhjue1cpaR
EBfgtnOGWRDHM+M0xxCIC3DvIENnh7ooQ8xHtAHvAlmCPVQg4sVDrYgIWtCAzfOWoCIDXCSo
uXl+EVRkgDPEpQEyR4/yAC9jF5+CXFQthEM+rNdoHiof1m/dTs6HzVs7Ih8mSDWIjJiBpvmr
iayYgaaJponMeBhde7kxA02ThFH5MQOeIfPCc2QSfL8s2al90DQZ1L7sNNmUglBpcuBaPE3G
IXGaHLXRvdJkUhczTS6M3Tp7FguRJnPQLN3lY0udPeGESJMZaJZPMucFEGkyA83ySYatn0qT
OXCeV3ihkjs2g0qTWXBWJPLCJXcWBZUms+A87bxuxIiZgjMbqDTZQsg0uejh7NJkFrz02e+l
yRx8yFlLpckDiFIXuDSZBS91gZcmc/A5F3hpMsOrOb5dOk1mCXDbubiNvDSZh2cGankzeWky
x0VcPPcCWVpWMk0mZ25empyd3Q1ySWbTZI65nMtEaXImozglTcZeI08WH8aTj8F56n+tj2/b
w81OllbetPuDSJW7thnJmgVZ39Cpgspm/XV03R/X6+7daPTP7bpbC9vWWkPXt0eoNjtsl9X+
cGxvRlWzGq3Wm7qBHxol/F5XGkU+uO6ls2/2B7MeYRYjrlN/KexMY+VCgllRuE6nzwp7qbGy
JgLA8hOleTqLzdCqUTOmsR3a5sQOKLmQaFN1IfDmIy1xaSWEzUZCfEQl2nol4WofDGyHoWCX
Bneugbg79JZZCQ630kZbvVFhGYZSUoVjpbkfUYNk3Eqki2QBd/+gMjIdkjJJGUhlWSfdd6BB
78mD8Hflxc8q/HWnN70/G/4I9qHCv9QMyuYXF/4lDjEBX+KPxwp59AlwNR9PJ1dhJdGq6uMH
C9S3fTHkh4oM1D5e5D92ZSdajdFYuSAT6JBfup3AWkSRocmqObk7VQaV+uStIcEX4lrpEpKF
y0sFiswPvkxiS3eomqU2Vol/Fl/oWxOf/Btzv2r80qDOMDfFotau/b/W5mH6DE9JQkp3QOTD
G8zLi2lqgbza+y2iA/Og7h2YouRGDBdqNPTJ/ei4N8YjXnMagPD/cCAkzmjar2eyujPJfnVz
iuQ39E3e2b5osz5ZdBd3n3LR7emiu9MN3haJjgJR278r3Qddy03iIKClRQOdLNsUXVfNHfTA
Gbxy+k4DJzw7XuaICffGGSq1N2xWNDw4MiVs1h5JlA2AmGjBkKfBz26sy/suGt3KwXYFtAS8
5YB3HDO2BPjHHJfQfSpTuet1Gu1TCZRv497PMGx3D4dsi2STFWt93SbxZ/yAyQknDuUI72KH
cYQTb7OufB+zE38jwnhL3dwjQtovLNlgjHKPr+oYm6Cfwya+w+05LzS+9QjFDOwCKSSiC6SQ
UC651kkWIsHrpH6oqEVH6Y+z8dSRLPoWwdqHcLVd+lArwt5/6V1omXWhjPl+07cruyYT1VYY
jKyMMIVtFGTa2+o6gIRXEpKrvt1Y4yIM6F6pGg0aInSvVI1GCHkdX0nau8nYq+tBNri9ILdx
tlgtkS0bZ0sKMSaqAg69i87uozXjmI4AZBx7lhEAnS8bAT7kySOAttdGAGrv40QANiZczBbj
i/kFNibIZUsxjMKq5dHwXZ2jkSCxWw62p7CvY2yONQ2vSyL5zTxLwC8CCRVRRrsPEd+pbeRL
qS8ohjI73rXvkN70XH03UKaRoTh7QN+he00/fBzP3AlNkL7Lo4iAaBVS+b6CxW54Ap6bH392
bystJVnwzgNWIli0YMk6BkjLRQyyIBentOqAd8KtBDiWixwLUyzmioZjgqB04V79vvSNSe9H
vg8wmtxrgADovR0AjWpbc1QTrdtN94HHaTcI0JA950FbDnSyWw4XS1sOcE/YcmgPnC7GkuYl
fBL4drU3ot3EzWlFUIODbX/XxpEb5mPf8NidEodo8WwL56iKiCbOce10hkzGH0G1gEiprIMm
5gRCdDTXAs2aKbDraQFg7IGmDB9Mz6ApB/vqSU053FtzDEPPtynRXjoX4+0inq/VtnRbtql9
3qYDjPzJtv0A7tB23qN7PLKfg7kDfMugFEomEmo8UzOJwdFMXUaNZfoibjJmHIPF/LN0DESf
JTX6Lo7BImi+uBjPF/ZlvCVK2lc31Wp1XO6r5m5zpv8TtyX+eg9qS/AOD2pL6syjZJf6JExd
2IjKTq/12cwm1u8DEJ2JOdV1F+l8qw4DABeYScsjuUAvJT25C9CouJqO51eW7CXRsmsGDVvu
2q0PEj3D+2+Kyxzar+tjXspzcY3zpkvN6j+/EUTeQ1oMxUFWk8mnjS79v9Om6YuQSNJu05H0
I7gNovDp3IYxFNkjsWkWJAc5kQXJKYiP3Z58ms4yHGyXYzcrFjOfuhstZm+v6757J4xYH9Ux
nOrshLU8DbJXlXrXbX8ryUK7en/Y/Td6A7nQm7Eq0tute1AlCRT//KyL9kZfb6se2EXrb/It
frUTknX3Th4U+vfvv44u3s/fCxtNPZ+9oFIdLA7/kv7sv4PRQ5lBwNzulWTUU2uE6n4di99z
u1/o9tTtwq9ld4u19kTks5Opz9/rjmsfHY5t30pF3StDX2gmm/7SvJGIKzDSqWz+lOFwfq1m
jYzTE+P1HcYJfYRoySlyhGjJSWfUVU83uOTEKEIUPczUX7TAGt6uemgl+JqHvZ77teyEJCQe
wgNeeQcgh+oU16C+0rTfp0pgKnPefzvY4k97jLgO82+N8Q4cx/6TnC79oU+YWv5mTl41fcyN
MY/Vx1yNU75zFdR2xAdHloDL6lHiQ/aKNHPMoOpRsh0hdt337gF6qYAZ+s5Kd2sFwe6QDxPl
/wOU7Ogc2/cAAA==
--------------8DF2D5BA86BB12328C66DD16--

59
doc/TODO.detail/default
View File

@ -1,59 +0,0 @@
From tgl@sss.pgh.pa.us Sun May 23 18:59:22 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 SAA08491
for <maillist@candle.pha.pa.us>; Sun, 23 May 1999 18:59:21 -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 SAA27952;
Sun, 23 May 1999 18:58:53 -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 18:58:52 -0400
Message-ID: <27950.927500332@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Status: ROr
Actually, it's not as fixed as all that...
create table foo1 (a char(5) default '', b int4);
insert into foo1 (b) values (334);
select * from foo1;
a | b
-----+---
|334
(1 row)
Good, the basic case is fixed, but:
create table foo2 (a char(5) default text '', b int4);
insert into foo2 (b) values (334);
select * from foo2;
a| b
-+--
|16
(1 row)
Ooops.
What you seem to have done is twiddle the handling of DEFAULT clauses
so that the value stored for the default expression is pre-coerced to the
column type. That's good as far as it goes, but it fails in cases where
the stored value has to be of a different type.
My guess is that what *really* ought to happen here is that
transformInsertStmt should check the type of the value it's gotten from
the default clause and apply coerce_type if necessary.
Unless someone can come up with a less artificial example than the one
above, I'm inclined to leave it alone for 6.5. This is the same code
area that will have to be redone to fix the INSERT ... SELECT problem
I was chasing earlier today: coercion of the values produced by SELECT
will have to wait until the tail end of transformInsertStmt, and we
might as well make wrong-type default constants get fixed in the same
place. So I'm not eager to write some throwaway code to patch a problem
that no one is likely to see in practice. What's your feeling about it?
regards, tom lane

483
doc/TODO.detail/distinct
View File

@ -1,483 +0,0 @@
From owner-pgsql-sql@hub.org Sat Jul 10 16:31:14 1999
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 QAA03701
for <maillist@candle.pha.pa.us>; Sat, 10 Jul 1999 16:31:13 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id QAA10295 for <maillist@candle.pha.pa.us>; Sat, 10 Jul 1999 16:29:57 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA13874;
Sat, 10 Jul 1999 16:23:11 -0400 (EDT)
(envelope-from owner-pgsql-sql@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sat, 10 Jul 1999 16:21:15 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id QAA13331
for pgsql-sql-outgoing; Sat, 10 Jul 1999 16:21:14 -0400 (EDT)
(envelope-from owner-pgsql-sql@postgreSQL.org)
X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-sql@postgreSQL.org using -f
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA13055;
Sat, 10 Jul 1999 16:16:42 -0400 (EDT)
(envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id AAA06017;
Sun, 11 Jul 1999 00:16:40 +0400 (MSD)
Date: Sun, 11 Jul 1999 00:16:39 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
Reply-To: Oleg Bartunov <oleg@sai.msu.su>
To: hackers@postgreSQL.org
cc: pgsql-sql@postgreSQL.org
Subject: [SQL] SELECT DISTINCT question
Message-ID: <Pine.GSO.3.96.SK.990711000908.2043R-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pgsql-sql@postgreSQL.org
Precedence: bulk
Status: RO
I got a problem with query:
select distinct (date), bytes from access_log;
which works but not as I expect. I thought this query will select
all rows with distinct values of 'date' column, but it get
distinct pairs 'date, bytes' . From documnetation I see
"DISTINCT will eliminate all duplicate rows from the selection.
DISTINCT ON column will eliminate all duplicates in the specified column;
this is equivalent to using GROUP BY column.
ALL will return all candidate rows, including duplicates."
discovery=> select distinct on date,bytes from access_log;
ERROR: parser: parse error at or near ","
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
From owner-pgsql-sql@hub.org Sat Jul 10 18:01:17 1999
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 SAA04878
for <maillist@candle.pha.pa.us>; Sat, 10 Jul 1999 18:01:16 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id RAA12755 for <maillist@candle.pha.pa.us>; Sat, 10 Jul 1999 17:35:02 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA24997;
Sat, 10 Jul 1999 17:28:17 -0400 (EDT)
(envelope-from owner-pgsql-sql@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sat, 10 Jul 1999 17:23:39 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id RAA24524
for pgsql-sql-outgoing; Sat, 10 Jul 1999 17:23:38 -0400 (EDT)
(envelope-from owner-pgsql-sql@postgreSQL.org)
X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-sql@postgreSQL.org using -f
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2] (may be forged))
by hub.org (8.9.3/8.9.3) with ESMTP id RAA24227;
Sat, 10 Jul 1999 17:19:43 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
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 RAA05709;
Sat, 10 Jul 1999 17:18:28 -0400 (EDT)
To: Oleg Bartunov <oleg@sai.msu.su>
cc: hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: [SQL] Re: [HACKERS] SELECT DISTINCT question
In-reply-to: Your message of Sun, 11 Jul 1999 00:16:39 +0400 (MSD)
<Pine.GSO.3.96.SK.990711000908.2043R-100000@ra>
Date: Sat, 10 Jul 1999 17:18:28 -0400
Message-ID: <5707.931641508@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Sender: owner-pgsql-sql@postgreSQL.org
Precedence: bulk
Status: RO
Oleg Bartunov <oleg@sai.msu.su> writes:
> discovery=> select distinct on date,bytes from access_log;
> ERROR: parser: parse error at or near ","
The syntax for SELECT DISTINCT ON is just as brain-damaged as the
functionality itself: there's no comma after the column name.
You want
select distinct on date date,bytes from access_log;
The reason the functionality is brain-damaged is that there's no way to
know which tuple out of the set of tuples with a given "date" value will
be the one returned.
SELECT DISTINCT ON is not in SQL92, and I think it shouldn't be in
Postgres either...
regards, tom lane
From owner-pgsql-sql@hub.org Sun Jul 11 12:01:23 1999
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 MAA26263
for <maillist@candle.pha.pa.us>; Sun, 11 Jul 1999 12:01:22 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id LAA14891 for <maillist@candle.pha.pa.us>; Sun, 11 Jul 1999 11:56:47 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA09165;
Sun, 11 Jul 1999 11:51:27 -0400 (EDT)
(envelope-from owner-pgsql-sql@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sun, 11 Jul 1999 11:49:46 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id LAA08263
for pgsql-sql-outgoing; Sun, 11 Jul 1999 11:49:45 -0400 (EDT)
(envelope-from owner-pgsql-sql@postgreSQL.org)
X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-sql@postgreSQL.org using -f
Received: from trends.net (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA05079;
Sun, 11 Jul 1999 11:41:38 -0400 (EDT)
(envelope-from oleg@sai.msu.su)
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by trends.net (8.8.8/8.8.8) with ESMTP id CAA21557;
Sun, 11 Jul 1999 02:23:01 -0400 (EDT)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id KAA18412;
Sun, 11 Jul 1999 10:09:24 +0400 (MSD)
Date: Sun, 11 Jul 1999 10:09:24 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [SQL] Re: [HACKERS] SELECT DISTINCT question
In-Reply-To: <5707.931641508@sss.pgh.pa.us>
Message-ID: <Pine.GSO.3.96.SK.990711100405.2043V-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pgsql-sql@postgreSQL.org
Precedence: bulk
Status: RO
On Sat, 10 Jul 1999, Tom Lane wrote:
> Date: Sat, 10 Jul 1999 17:18:28 -0400
> From: Tom Lane <tgl@sss.pgh.pa.us>
> To: Oleg Bartunov <oleg@sai.msu.su>
> Cc: hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
> Subject: [SQL] Re: [HACKERS] SELECT DISTINCT question
>
> Oleg Bartunov <oleg@sai.msu.su> writes:
> > discovery=> select distinct on date,bytes from access_log;
> > ERROR: parser: parse error at or near ","
>
> The syntax for SELECT DISTINCT ON is just as brain-damaged as the
> functionality itself: there's no comma after the column name.
> You want
>
> select distinct on date date,bytes from access_log;
>
thanks, this works. But why parser complains about such query:
discovery=> select distinct on a.date a.date, a.bytes from access_log a;
ERROR: parser: parse error at or near "."
In this query I could just omit '.', but in more complex query
I probably could need one.
> The reason the functionality is brain-damaged is that there's no way to
> know which tuple out of the set of tuples with a given "date" value will
> be the one returned.
>
> SELECT DISTINCT ON is not in SQL92, and I think it shouldn't be in
> Postgres either...
I'm not an SQL expert, but if it works and this feature is in standard
but only syntax is diffrent, why just not to use standard
select distinct(date), bytes from access_log;
Or I'm missing here ?
Regards,
Oleg
>
> regards, tom lane
>
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
From owner-pgsql-hackers@hub.org Sun Jul 11 12:01:26 1999
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 MAA26269
for <maillist@candle.pha.pa.us>; Sun, 11 Jul 1999 12:01:25 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id LAA15017 for <maillist@candle.pha.pa.us>; Sun, 11 Jul 1999 11:59:07 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA09118;
Sun, 11 Jul 1999 11:51:21 -0400 (EDT)
(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sun, 11 Jul 1999 11:49:44 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id LAA06345
for pgsql-hackers-outgoing; Sun, 11 Jul 1999 11:46:14 -0400 (EDT)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-hackers@postgreSQL.org using -f
Received: from trends.net (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA05079;
Sun, 11 Jul 1999 11:41:38 -0400 (EDT)
(envelope-from oleg@sai.msu.su)
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
by trends.net (8.8.8/8.8.8) with ESMTP id CAA21557;
Sun, 11 Jul 1999 02:23:01 -0400 (EDT)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id KAA18412;
Sun, 11 Jul 1999 10:09:24 +0400 (MSD)
Date: Sun, 11 Jul 1999 10:09:24 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [SQL] Re: [HACKERS] SELECT DISTINCT question
In-Reply-To: <5707.931641508@sss.pgh.pa.us>
Message-ID: <Pine.GSO.3.96.SK.990711100405.2043V-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: RO
On Sat, 10 Jul 1999, Tom Lane wrote:
> Date: Sat, 10 Jul 1999 17:18:28 -0400
> From: Tom Lane <tgl@sss.pgh.pa.us>
> To: Oleg Bartunov <oleg@sai.msu.su>
> Cc: hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
> Subject: [SQL] Re: [HACKERS] SELECT DISTINCT question
>
> Oleg Bartunov <oleg@sai.msu.su> writes:
> > discovery=> select distinct on date,bytes from access_log;
> > ERROR: parser: parse error at or near ","
>
> The syntax for SELECT DISTINCT ON is just as brain-damaged as the
> functionality itself: there's no comma after the column name.
> You want
>
> select distinct on date date,bytes from access_log;
>
thanks, this works. But why parser complains about such query:
discovery=> select distinct on a.date a.date, a.bytes from access_log a;
ERROR: parser: parse error at or near "."
In this query I could just omit '.', but in more complex query
I probably could need one.
> The reason the functionality is brain-damaged is that there's no way to
> know which tuple out of the set of tuples with a given "date" value will
> be the one returned.
>
> SELECT DISTINCT ON is not in SQL92, and I think it shouldn't be in
> Postgres either...
I'm not an SQL expert, but if it works and this feature is in standard
but only syntax is diffrent, why just not to use standard
select distinct(date), bytes from access_log;
Or I'm missing here ?
Regards,
Oleg
>
> regards, tom lane
>
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
From owner-pgsql-sql@hub.org Sun Jul 11 12:01:16 1999
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 MAA26248
for <maillist@candle.pha.pa.us>; Sun, 11 Jul 1999 12:01:15 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id LAA14635 for <maillist@candle.pha.pa.us>; Sun, 11 Jul 1999 11:52:26 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA07748;
Sun, 11 Jul 1999 11:47:08 -0400 (EDT)
(envelope-from owner-pgsql-sql@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sun, 11 Jul 1999 11:44:34 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id LAA05445
for pgsql-sql-outgoing; Sun, 11 Jul 1999 11:44:33 -0400 (EDT)
(envelope-from owner-pgsql-sql@postgreSQL.org)
X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-sql@postgreSQL.org using -f
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2] (may be forged))
by hub.org (8.9.3/8.9.3) with ESMTP id LAA04477;
Sun, 11 Jul 1999 11:40:31 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
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 LAA15131;
Sun, 11 Jul 1999 11:38:44 -0400 (EDT)
To: Oleg Bartunov <oleg@sai.msu.su>
cc: hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: Re: [SQL] Re: [HACKERS] SELECT DISTINCT question
In-reply-to: Your message of Sun, 11 Jul 1999 10:09:24 +0400 (MSD)
<Pine.GSO.3.96.SK.990711100405.2043V-100000@ra>
Date: Sun, 11 Jul 1999 11:38:43 -0400
Message-ID: <15129.931707523@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Sender: owner-pgsql-sql@postgreSQL.org
Precedence: bulk
Status: RO
Oleg Bartunov <oleg@sai.msu.su> writes:
> thanks, this works. But why parser complains about such query:
> discovery=> select distinct on a.date a.date, a.bytes from access_log a;
> ERROR: parser: parse error at or near "."
Probably the grammar specifies just <column name> and not anything
more complex after DISTINCT ON. It'd be risky to try to accept a
general expression after ON, due to the silly decision to leave out
any terminating punctuation.
>> SELECT DISTINCT ON is not in SQL92, and I think it shouldn't be in
>> Postgres either...
> I'm not an SQL expert, but if it works and this feature is in standard
> but only syntax is diffrent,
No, there is no feature in SQL that allows DISTINCT on a subset of
columns, period. This is not merely a matter of syntax, it's a
fundamental semantic issue.
> why just not to use standard
>
> select distinct(date), bytes from access_log;
>
> Or I'm missing here ?
I don't think that does what you expect it to (hint: the
parentheses are redundant).
regards, tom lane
From owner-pgsql-sql@hub.org Tue Jul 13 18:02:01 1999
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 SAA07953
for <maillist@candle.pha.pa.us>; Tue, 13 Jul 1999 18:02:00 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id RAA14528 for <maillist@candle.pha.pa.us>; Tue, 13 Jul 1999 17:46:12 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA96029;
Tue, 13 Jul 1999 17:42:37 -0400 (EDT)
(envelope-from owner-pgsql-sql@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Tue, 13 Jul 1999 17:33:35 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id RAA94598
for pgsql-sql-outgoing; Tue, 13 Jul 1999 17:33:33 -0400 (EDT)
(envelope-from owner-pgsql-sql@postgreSQL.org)
X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-sql@postgreSQL.org using -f
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA94565;
Tue, 13 Jul 1999 17:33:19 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
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 RAA24415;
Tue, 13 Jul 1999 17:31:49 -0400 (EDT)
To: Hannu Krosing <hannu@trust.ee>
cc: hackers@postgreSQL.org, pgsql-sql@postgreSQL.org
Subject: [SQL] Re: [HACKERS] SELECT DISTINCT question
In-reply-to: Your message of Tue, 13 Jul 1999 23:50:57 +0300
<378BA6B1.2B226DDB@trust.ee>
Date: Tue, 13 Jul 1999 17:31:48 -0400
Message-ID: <24413.931901508@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Sender: owner-pgsql-sql@postgreSQL.org
Precedence: bulk
Status: ROr
Hannu Krosing <hannu@trust.ee> writes:
>> "DISTINCT will eliminate all duplicate rows from the selection.
>> DISTINCT ON column will eliminate all duplicates in the specified column;
>> this is equivalent to using GROUP BY column."
> If it is equivalent to GROUP BY then it should allow only aggregates
> in non-distinct columns, like:
> select distinct on date date, sum(bytes) from access_log;
> If it does not, then it should be files as a bug imho.
It does not. Whether that is a bug is hard to say, since there is no
standard I know of that says what it *is* supposed to do.
If you look at the select_distinct_on regress test outputs, I bet you
will be even less happy:
QUERY: SELECT DISTINCT ON string4 two, string4, ten
FROM tmp
ORDER BY two using <, string4 using <, ten using <;
two|string4|ten
---+-------+---
0|AAAAxx | 0
0|HHHHxx | 0
0|OOOOxx | 0
0|VVVVxx | 0
1|AAAAxx | 1
1|HHHHxx | 1
1|OOOOxx | 1
1|VVVVxx | 1
(8 rows)
That's not exactly my idea of "distinct" values of string4 ---
but apparently whoever made up the regress test thought it was OK!
Can anyone defend this feature or provide a coherent definition
of what it's supposed to be doing? My urge to rip it out is
growing stronger and stronger...
regards, tom lane
From tgl@sss.pgh.pa.us Thu Sep 23 17:27:49 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id RAA25975
for <maillist@candle.pha.pa.us>; Thu, 23 Sep 1999 17:27:48 -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 RAA15769;
Thu, 23 Sep 1999 17:27:38 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Hannu Krosing <hannu@trust.ee>, hackers@postgreSQL.org,
pgsql-sql@postgreSQL.org
Subject: Re: [SQL] Re: [HACKERS] SELECT DISTINCT question
In-reply-to: Your message of Thu, 23 Sep 1999 13:18:18 -0400 (EDT)
<199909231718.NAA19629@candle.pha.pa.us>
Date: Thu, 23 Sep 1999 17:27:37 -0400
Message-ID: <15767.938122057@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Status: ROr
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Tom, any status on this DISTINCT ON ripout?
I haven't done anything about it, if that's what you mean.
I didn't get any indication of whether anyone else agreed with me
(maybe the lack of loud complaints should be taken as consent?)
regards, tom lane

351
doc/TODO.detail/flock
View File

@ -1,351 +0,0 @@
From tgl@sss.pgh.pa.us Sun Aug 30 11:25:23 1998
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6])
by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id LAA12607
for <maillist@candle.pha.pa.us>; Sun, 30 Aug 1998 11:25:20 -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 LAA15788;
Sun, 30 Aug 1998 11:23:38 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: dz@cs.unitn.it (Massimo Dal Zotto), hackers@postgreSQL.org
Subject: Re: [HACKERS] flock patch breaks things here
In-reply-to: Your message of Sun, 30 Aug 1998 08:19:52 -0400 (EDT)
<199808301219.IAA08821@candle.pha.pa.us>
Date: Sun, 30 Aug 1998 11:23:38 -0400
Message-ID: <15786.904490618@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Status: RO
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Can't we just have configure check for flock(). Another idea is to
> create a 'pid' file in the pgsql/data/base directory, and do a kill -0
> to see if it is stil running before removing the lock.
The latter approach is what I was going to suggest. Writing a pid file
would be a fine idea anyway --- for one thing, it makes it a lot easier
to write a "kill the postmaster" script. Given that the postmaster
should write a pid file, a new postmaster should look for an existing
pid file, and try to do a kill(pid, 0) on the number contained therein.
If this doesn't return an error, then you figure there is already a
postmaster running, complain, and exit. Otherwise you figure you is it,
(re)write the pid file and away you go. Then pqcomm.c can just
unconditionally delete any old file that's in the way of making the
pipe.
The pidfile checking and creation probably ought to go in postmaster.c,
not down inside pqcomm.c. I never liked the fact that a critical
interlock function was being done by a low-level library that one might
not even want to invoke (if all your clients are using TCP, opening up
the Unix-domain socket is a waste of time, no?).
BTW, there is another problem with relying on flock on the socket file
for this purpose: it opens up a hole for a denial-of-service attack.
Anyone who can write the file can flock it. (We already had a problem
with DOS via creating a dummy file at /tmp/.s.PGSQL.5432, but it would
be harder to spot the culprit with an flock-based interference.)
regards, tom lane
From owner-pgsql-hackers@hub.org Sun Aug 30 12:27:41 1998
Received: from hub.org (hub.org [209.47.148.200])
by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id MAA12976
for <maillist@candle.pha.pa.us>; Sun, 30 Aug 1998 12:27:37 -0400 (EDT)
Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id MAA09234; Sun, 30 Aug 1998 12:24:51 -0400 (EDT)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sun, 30 Aug 1998 12:23:26 +0000 (EDT)
Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id MAA09167 for pgsql-hackers-outgoing; Sun, 30 Aug 1998 12:23:25 -0400 (EDT)
Received: from mambo.cs.unitn.it (mambo.cs.unitn.it [193.205.199.204]) by hub.org (8.8.8/8.7.5) with SMTP id MAA09150 for <hackers@postgreSQL.org>; Sun, 30 Aug 1998 12:23:08 -0400 (EDT)
Received: from boogie.cs.unitn.it (dz@boogie [193.205.199.79]) by mambo.cs.unitn.it (8.6.12/8.6.12) with ESMTP id SAA29572; Sun, 30 Aug 1998 18:21:42 +0200
Received: (from dz@localhost) by boogie.cs.unitn.it (8.8.5/8.6.9) id SAA05993; Sun, 30 Aug 1998 18:21:41 +0200
From: Massimo Dal Zotto <dz@cs.unitn.it>
Message-Id: <199808301621.SAA05993@boogie.cs.unitn.it>
Subject: Re: [HACKERS] flock patch breaks things here
To: hackers@postgreSQL.org (PostgreSQL Hackers)
Date: Sun, 30 Aug 1998 18:21:41 +0200 (MET DST)
Cc: tgl@sss.pgh.pa.us (Tom Lane)
In-Reply-To: <15786.904490618@sss.pgh.pa.us> from "Tom Lane" at Aug 30, 98 11:23:38 am
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-hackers@hub.org
Precedence: bulk
Status: ROr
>
> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > Can't we just have configure check for flock(). Another idea is to
> > create a 'pid' file in the pgsql/data/base directory, and do a kill -0
> > to see if it is stil running before removing the lock.
>
> The latter approach is what I was going to suggest. Writing a pid file
> would be a fine idea anyway --- for one thing, it makes it a lot easier
> to write a "kill the postmaster" script. Given that the postmaster
> should write a pid file, a new postmaster should look for an existing
> pid file, and try to do a kill(pid, 0) on the number contained therein.
> If this doesn't return an error, then you figure there is already a
> postmaster running, complain, and exit. Otherwise you figure you is it,
> (re)write the pid file and away you go. Then pqcomm.c can just
> unconditionally delete any old file that's in the way of making the
> pipe.
>
> The pidfile checking and creation probably ought to go in postmaster.c,
> not down inside pqcomm.c. I never liked the fact that a critical
> interlock function was being done by a low-level library that one might
> not even want to invoke (if all your clients are using TCP, opening up
> the Unix-domain socket is a waste of time, no?).
>
> BTW, there is another problem with relying on flock on the socket file
> for this purpose: it opens up a hole for a denial-of-service attack.
> Anyone who can write the file can flock it. (We already had a problem
> with DOS via creating a dummy file at /tmp/.s.PGSQL.5432, but it would
> be harder to spot the culprit with an flock-based interference.)
This came to my mind, but I didn't think this would have happened so
quickly. In my opinion the socket and the pidfile should be created in a
directory owned by postgres, for example /tmp/.Pgsql-unix, like does X.
--
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 |
+----------------------------------------------------------------------+
From owner-pgsql-hackers@hub.org Sun Aug 30 13:01:10 1998
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id NAA13785
for <maillist@candle.pha.pa.us>; Sun, 30 Aug 1998 13:01:09 -0400 (EDT)
Received: from hub.org (hub.org [209.47.148.200]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id MAA29386 for <maillist@candle.pha.pa.us>; Sun, 30 Aug 1998 12:58:24 -0400 (EDT)
Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id MAA11406; Sun, 30 Aug 1998 12:54:48 -0400 (EDT)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sun, 30 Aug 1998 12:52:22 +0000 (EDT)
Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id MAA11310 for pgsql-hackers-outgoing; Sun, 30 Aug 1998 12:52:20 -0400 (EDT)
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.8.8/8.7.5) with ESMTP id MAA11296 for <hackers@postgreSQL.org>; Sun, 30 Aug 1998 12:52:13 -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 MAA16094;
Sun, 30 Aug 1998 12:50:55 -0400 (EDT)
To: Massimo Dal Zotto <dz@cs.unitn.it>
cc: hackers@postgreSQL.org (PostgreSQL Hackers)
Subject: Re: [HACKERS] flock patch breaks things here
In-reply-to: Your message of Sun, 30 Aug 1998 18:21:41 +0200 (MET DST)
<199808301621.SAA05993@boogie.cs.unitn.it>
Date: Sun, 30 Aug 1998 12:50:55 -0400
Message-ID: <16092.904495855@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Sender: owner-pgsql-hackers@hub.org
Precedence: bulk
Status: RO
Massimo Dal Zotto <dz@cs.unitn.it> writes:
> In my opinion the socket and the pidfile should be created in a
> directory owned by postgres, for example /tmp/.Pgsql-unix, like does X.
The pidfile belongs at the top level of the database directory (eg,
/usr/local/pgsql/data/postmaster.pid), because what it actually
represents is that there is a postmaster running *for that database
group*.
If you want to support multiple database sets on one machine (which I
do), then the interlock has to be per database directory. Putting the
pidfile into a common directory would mean we'd have to invent some
kind of pidfile naming convention to keep multiple postmasters from
tromping on each other. This is unnecessarily complex.
I agree with you that putting the socket file into a less easily munged
directory than /tmp would be a good idea for security. But that's a
separate issue. On machines that understand stickybits for directories,
the security hole is not really very big.
At this point, the fact that /tmp/.s.PGSQL.port# is the socket path is
effectively a version-independent aspect of the FE/BE protocol, and so
we can't change it without breaking old applications. I'm not sure that
that's worth the security improvement.
What I'd like to see someday is a postmaster command line switch to tell
it to use *only* TCP connections and not create a Unix socket at all.
That hasn't been possible so far, because we were relying on the socket
file to provide a safety interlock against starting multiple
postmasters. But an interlock using a pidfile would be much better.
(Look around; *every* other Unix daemon I know of that wants to ensure
that there's only one of it uses a pidfile interlock. Not file locking.
There's a reason why that's the well-trodden path.)
regards, tom lane
From owner-pgsql-hackers@hub.org Sun Aug 30 15:31:13 1998
Received: from hub.org (hub.org [209.47.148.200])
by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id PAA15275
for <maillist@candle.pha.pa.us>; Sun, 30 Aug 1998 15:31:11 -0400 (EDT)
Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id PAA22194; Sun, 30 Aug 1998 15:27:20 -0400 (EDT)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sun, 30 Aug 1998 15:23:58 +0000 (EDT)
Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id PAA21800 for pgsql-hackers-outgoing; Sun, 30 Aug 1998 15:23:57 -0400 (EDT)
Received: from thelab.hub.org (nat0118.mpoweredpc.net [142.177.188.118]) by hub.org (8.8.8/8.7.5) with ESMTP id PAA21696 for <hackers@postgreSQL.org>; Sun, 30 Aug 1998 15:22:51 -0400 (EDT)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.1/8.8.8) with SMTP id QAA18542;
Sun, 30 Aug 1998 16:21:29 -0300 (ADT)
(envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 30 Aug 1998 16:21:28 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Massimo Dal Zotto <dz@cs.unitn.it>,
PostgreSQL Hackers <hackers@postgreSQL.org>
Subject: Re: [HACKERS] flock patch breaks things here
In-Reply-To: <16092.904495855@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.02.9808301618350.343-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pgsql-hackers@hub.org
Precedence: bulk
Status: RO
On Sun, 30 Aug 1998, Tom Lane wrote:
> Massimo Dal Zotto <dz@cs.unitn.it> writes:
> > In my opinion the socket and the pidfile should be created in a
> > directory owned by postgres, for example /tmp/.Pgsql-unix, like does X.
>
> The pidfile belongs at the top level of the database directory (eg,
> /usr/local/pgsql/data/postmaster.pid), because what it actually
> represents is that there is a postmaster running *for that database
> group*.
I have to agree with this one...but then it also negates the
argument about the flock() DoS...*grin*
BTW...I like the kill(pid,0) solution myself, primarily because it
is, i think, the most portable solution.
I would not consider a patch to remove the flock() solution and
replace it with the kill(pid,0) solution a new feature, just an
improvement of an existing one...either way, moving the pid file (or
socket, for that matter) from /tmp should be listed as a security related
requirement for v6.4 :)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From owner-pgsql-hackers@hub.org Sun Aug 30 22:41:10 1998
Received: from hub.org (hub.org [209.47.148.200])
by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id WAA01526
for <maillist@candle.pha.pa.us>; Sun, 30 Aug 1998 22:41:08 -0400 (EDT)
Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id WAA29298; Sun, 30 Aug 1998 22:38:18 -0400 (EDT)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sun, 30 Aug 1998 22:35:05 +0000 (EDT)
Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id WAA29203 for pgsql-hackers-outgoing; Sun, 30 Aug 1998 22:35:03 -0400 (EDT)
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.8.8/8.7.5) with ESMTP id WAA29017 for <hackers@postgreSQL.org>; Sun, 30 Aug 1998 22:34:55 -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 WAA20075;
Sun, 30 Aug 1998 22:34:41 -0400 (EDT)
To: The Hermit Hacker <scrappy@hub.org>
cc: PostgreSQL Hackers <hackers@postgreSQL.org>
Subject: Re: [HACKERS] flock patch breaks things here
In-reply-to: Your message of Sun, 30 Aug 1998 16:21:28 -0300 (ADT)
<Pine.BSF.4.02.9808301618350.343-100000@thelab.hub.org>
Date: Sun, 30 Aug 1998 22:34:40 -0400
Message-ID: <20073.904530880@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Sender: owner-pgsql-hackers@hub.org
Precedence: bulk
Status: ROr
The Hermit Hacker <scrappy@hub.org> writes:
> either way, moving the pid file (or
> socket, for that matter) from /tmp should be listed as a security related
> requirement for v6.4 :)
Huh? There is no pid file being generated in /tmp (or anywhere else)
at the moment. If we do add one, it should not go into /tmp for the
reasons I gave before.
Where the Unix-domain socket file lives is an entirely separate issue.
If we move the socket out of /tmp then we have just kicked away all the
work we did to preserve backwards compatibility of the FE/BE protocol
with existing clients. Being able to talk to a 1.0 client isn't much
good if you aren't listening where he's going to try to contact you.
So I think I have to vote in favor of leaving the socket where it is.
regards, tom lane
From owner-pgsql-hackers@hub.org Mon Aug 31 11:31:19 1998
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id LAA21195
for <maillist@candle.pha.pa.us>; Mon, 31 Aug 1998 11:31:13 -0400 (EDT)
Received: from hub.org (hub.org [209.47.148.200]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id LAA06827 for <maillist@candle.pha.pa.us>; Mon, 31 Aug 1998 11:17:41 -0400 (EDT)
Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id LAA24792; Mon, 31 Aug 1998 11:12:18 -0400 (EDT)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Mon, 31 Aug 1998 11:10:31 +0000 (EDT)
Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id LAA24742 for pgsql-hackers-outgoing; Mon, 31 Aug 1998 11:10:29 -0400 (EDT)
Received: from trillium.nmsu.edu (trillium.NMSU.Edu [128.123.5.15]) by hub.org (8.8.8/8.7.5) with ESMTP id LAA24725 for <hackers@postgreSQL.org>; Mon, 31 Aug 1998 11:10:22 -0400 (EDT)
Received: (from brook@localhost)
by trillium.nmsu.edu (8.8.8/8.8.8) id JAA03282;
Mon, 31 Aug 1998 09:09:01 -0600 (MDT)
Date: Mon, 31 Aug 1998 09:09:01 -0600 (MDT)
Message-Id: <199808311509.JAA03282@trillium.nmsu.edu>
From: Brook Milligan <brook@trillium.NMSU.Edu>
To: tgl@sss.pgh.pa.us
CC: dg@informix.com, hackers@postgreSQL.org
In-reply-to: <23042.904573041@sss.pgh.pa.us> (message from Tom Lane on Mon, 31
Aug 1998 10:17:21 -0400)
Subject: Re: [HACKERS] flock patch breaks things here
References: <23042.904573041@sss.pgh.pa.us>
Sender: owner-pgsql-hackers@hub.org
Precedence: bulk
Status: ROr
I just came up with an idea that might help alleviate the /tmp security
exposure without creating a backwards-compatibility problem. It works
like this:
1. During installation, create a subdirectory of /tmp to hold Postgres'
socket files and associated pid lockfiles. This subdirectory should be
owned by the Postgres superuser and have permissions 755
(world-readable, writable only by Postgres superuser). Maybe call it
/tmp/.pgsql --- the name should start with a dot to keep it out of the
way. (Bruce points out that some systems clear /tmp during reboot, so
it might be that a postmaster will have to be prepared to recreate this
directory at startup --- anyone know if subdirectories of /tmp are
zapped too? My system doesn't do that...)
...
I notice that on my system, the X11 socket files in /tmp/.X11-unix are
actually symlinks to socket files in /usr/spool/sockets/X11. I dunno if
it's worth our trouble to get into putting our sockets under /usr/spool
or /var/spool or whatever --- seems like another configuration choice to
mess up. It'd be nice if the socket directory lived somewhere where the
parent dirs weren't world-writable, but this would mean one more thing
that you have to have root permissions for in order to install pgsql.
It seems like we need a directory for locks (= pid files) and one for
sockets (perhaps the same one). I strongly suggest that the location
for these be configurable. By default, it might make sense to put
them in ~pgsql/locks and ~pgsql/sockets. It is easy (i.e., I'll be
glad to do it) to modify configure.in to take options like
--lock-dir=/var/spool/lock
--socket-dir=/var/spool/sockets
that set cc defines and have the code respond accordingly. This way,
those who don't care (or don't have root access) can use the defaults,
whereas those with root access who like to keep locks and sockets in a
common place can do so easily. Either way, multiple postmasters (all
compiled with the same options of course) can check the appropriate
locks in the well-known places. Finally, drop the link into /tmp for
the old socket and document that it will be disappearing at some
point, and all is fine.
If someone wants to give me some guidance on what preprocessor
variables should be set in response to the above options (or something
like them), I'll do the configure stuff.
Cheers,
Brook

69
doc/TODO.detail/fsync
View File

@ -1,69 +0,0 @@
From owner-pgsql-general@hub.org Fri Dec 18 06:31:23 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 GAA05554
for <maillist@candle.pha.pa.us>; Fri, 18 Dec 1998 06:31:21 -0500 (EST)
Received: from hub.org (majordom@hub.org [209.47.145.100]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id EAA21127 for <maillist@candle.pha.pa.us>; Fri, 18 Dec 1998 04:46:38 -0500 (EST)
Received: from localhost (majordom@localhost)
by hub.org (8.9.1/8.9.1) with SMTP id EAA01409;
Fri, 18 Dec 1998 04:44:19 -0500 (EST)
(envelope-from owner-pgsql-general@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Fri, 18 Dec 1998 04:43:22 +0000 (EST)
Received: (from majordom@localhost)
by hub.org (8.9.1/8.9.1) id EAA01093
for pgsql-general-outgoing; Fri, 18 Dec 1998 04:43:18 -0500 (EST)
(envelope-from owner-pgsql-general@postgreSQL.org)
Received: from dune.krs.ru (dune.krs.ru [195.161.16.38])
by hub.org (8.9.1/8.9.1) with ESMTP id EAA01067
for <pgsql-general@postgreSQL.org>; Fri, 18 Dec 1998 04:43:09 -0500 (EST)
(envelope-from vadim@krs.ru)
Received: from krs.ru (localhost.krs.ru [127.0.0.1])
by dune.krs.ru (8.8.8/8.8.7) with ESMTP id QAA16201;
Fri, 18 Dec 1998 16:41:44 +0700 (KRS)
(envelope-from vadim@krs.ru)
Message-ID: <367A2354.E998763@krs.ru>
Date: Fri, 18 Dec 1998 16:41:40 +0700
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Anton de Wet <adw@obsidian.co.za>
CC: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Why PostgreSQL is better than other commerial softwares?
References: <Pine.LNX.4.04.9812181046030.9458-100000@ra.obsidian.co.za>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pgsql-general@postgreSQL.org
Precedence: bulk
Status: RO
Anton de Wet wrote:
>
> >
> > Often quick mailing list support?
>
> :-)
>
> While on the subject I finally found the solution to a problem I (and one
> or two other people) posted about without answer. (So sometimes it's slow
> mailing list support).
>
> In importing about 5 million records (which I copy in blocks of 10000) the
> copy became linearly slower. After a friend RTFM and refered me, I used
> the -F switch (passed by the postmaster to the backend processes) and the
> time became linear and a LOT shorter. Import time for the 5000000 records
> now the same (or maybe even slightly faster, I didn't accurately time
> them) as importing the data into oracle on the same machine.
"While on the subject..." -:)
This is the problem of buffer manager, known for very long time:
when copy eats all buffers, manager begins write/fsync each
durty buffer to free buffer for new data. All updated relations
should be fsynced _once_ @ transaction commit. You would get
the same results without -F...
I still have no time to implement this -:(
Vadim

616
doc/TODO.detail/function
View File

@ -1,616 +0,0 @@
From tgl@sss.pgh.pa.us Mon Jun 14 20:50:41 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 UAA19110
for <maillist@candle.pha.pa.us>; Mon, 14 Jun 1999 20:50:39 -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 UAA21506;
Mon, 14 Jun 1999 20:51:07 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Roman.Hodek@informatik.uni-erlangen.de, olly@lfix.co.uk,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Cleaning up function interface (was Re: Patch for m68k architecture)
In-reply-to: Your message of Mon, 14 Jun 1999 17:53:25 -0400 (EDT)
<199906142153.RAA16276@candle.pha.pa.us>
Date: Mon, 14 Jun 1999 20:51:06 -0400
Message-ID: <21504.929407866@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Status: RO
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> ANSI C says results are undefined if you call a function via pointer
>> and the pointer is declared to return another type than the function
>> actually returns. So m68k compilers conform to the standard here.
> Yes, we admit that we break the standard with fmgr_ptr, because we
> return a variety of values depending on what function they call. It
> appears the egcs optimization on the powerpc or alpha cause a problem
> when optimization is -O2, but not -O. We may see more platforms with
> problems as optimizers get smarter.
Seeing as how we also know that the function-call interface ought to be
redesigned to handle NULLs better, maybe we should just bite the bullet
and fix all of these problems at once by adopting a new standard
interface for everything that can be called via fmgr. It'd uglify the
code, no doubt, but I think we are starting to see an accumulation of
problems that justify doing something.
Here is a straw-man proposal:
Datum function (bool *resultnull,
Datum *args,
bool *argnull,
int nargs)
args[i] is the i'th parameter, or undefined (perhaps always 0?)
when argnull[i] is true. The function is responsible for setting
*resultnull, and returns a Datum value if *resultnull is false.
Most standard functions could ignore nargs since they'd know what it
should be, but we ought to pass it for flexibility.
A useful addition to this scheme would be for fmgr to preset *resultnull
to the OR of the input argnull[] array just before calling the function.
In the typical case where the function is "strict" (ie, result is NULL
if any input is NULL), this would save the function from having to look
at argnull[] at all; it'd just check *resultnull and immediately return
if true.
As an example, int4 addition goes from
int32
int4pl(int32 arg1, int32 arg2)
{
return arg1 + arg2;
}
to
Datum
int4pl (bool *resultnull, Datum *args, bool *argnull, int nargs)
{
if (*resultnull)
return (Datum) 0; /* value doesn't really matter ... */
/* we can ignore argnull and nargs */
return Int32GetDatum(DatumGetInt32(args[0]) + DatumGetInt32(args[1]));
}
This is, of course, much uglier than the existing code, but we might be
able to improve matters with some well-chosen macros for the boilerplate
parts. What we actually end up writing might look something like
Datum
int4pl (PG_FUNCTION_ARGS)
{
PG_STRICT_FUNCTION( /* encapsulates null check */
PG_ARG0_INT32;
PG_ARG1_INT32;
PG_RESULT_INT32( arg0 + arg1 );
);
}
where the macros expand to things like "int32 arg0 = DatumGetInt32(args[0])"
and "return Int32GetDatum( x )". It'd be worth a little thought to
try to set up a group of macros like that, I think.
regards, tom lane
From owner-pgsql-hackers@hub.org Wed Sep 22 20:31:02 1999
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 UAA15611
for <maillist@candle.pha.pa.us>; Wed, 22 Sep 1999 20:31:01 -0400 (EDT)
Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id UAA02926 for <maillist@candle.pha.pa.us>; Wed, 22 Sep 1999 20:21:24 -0400 (EDT)
Received: from hub.org (hub.org [216.126.84.1])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA75413;
Wed, 22 Sep 1999 20:09:35 -0400 (EDT)
(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Wed, 22 Sep 1999 20:08:50 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id UAA75058
for pgsql-hackers-outgoing; Wed, 22 Sep 1999 20:06:58 -0400 (EDT)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA74982
for <pgsql-hackers@postgreSQL.org>; Wed, 22 Sep 1999 20:06:25 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
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 UAA06411
for <pgsql-hackers@postgreSQL.org>; Wed, 22 Sep 1999 20:05:40 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] Progress report: buffer refcount bugs and SQL functions
Date: Wed, 22 Sep 1999 20:05:39 -0400
Message-ID: <6408.938045139@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: RO
I have been finding a lot of interesting stuff while looking into
the buffer reference count/leakage issue.
It turns out that there were two specific things that were camouflaging
the existence of bugs in this area:
1. The BufferLeakCheck routine that's run at transaction commit was
only looking for nonzero PrivateRefCount to indicate a missing unpin.
It failed to notice nonzero LastRefCount --- which meant that an
error in refcount save/restore usage could leave a buffer pinned,
and BufferLeakCheck wouldn't notice.
2. The BufferIsValid macro, which you'd think just checks whether
it's handed a valid buffer identifier or not, actually did more:
it only returned true if the buffer ID was valid *and* the buffer
had positive PrivateRefCount. That meant that the common pattern
if (BufferIsValid(buf))
ReleaseBuffer(buf);
wouldn't complain if it were handed a valid but already unpinned buffer.
And that behavior masks bugs that result in buffers being unpinned too
early. For example, consider a sequence like
1. LockBuffer (buffer now has refcount 1). Store reference to
a tuple on that buffer page in a tuple table slot.
2. Copy buffer reference to a second tuple-table slot, but forget to
increment buffer's refcount.
3. Release second tuple table slot. Buffer refcount drops to 0,
so it's unpinned.
4. Release original tuple slot. Because of BufferIsValid behavior,
no assert happens here; in fact nothing at all happens.
This is, of course, buggy code: during the interval from 3 to 4 you
still have an apparently valid tuple reference in the original slot,
which someone might try to use; but the buffer it points to is unpinned
and could be replaced at any time by another backend.
In short, we had errors that would mask both missing-pin bugs and
missing-unpin bugs. And naturally there were a few such bugs lurking
behind them...
3. The buffer refcount save/restore stuff, which I had suspected
was useless, is not only useless but also buggy. The reason it's
buggy is that it only works if used in a nested fashion. You could
save state A, pin some buffers, save state B, pin some more
buffers, restore state B (thereby unpinning what you pinned since
the save), and finally restore state A (unpinning the earlier stuff).
What you could not do is save state A, pin, save B, pin more, then
restore state A --- that might unpin some of A's buffers, or some
of B's buffers, or some unforeseen combination thereof. If you
restore A and then restore B, you do not necessarily return to a zero-
pins state, either. And it turns out the actual usage pattern was a
nearly random sequence of saves and restores, compounded by a failure to
do all of the restores reliably (which was masked by the oversight in
BufferLeakCheck).
What I have done so far is to rip out the buffer refcount save/restore
support (including LastRefCount), change BufferIsValid to a simple
validity check (so that you get an assert if you unpin something that
was pinned), change ExecStoreTuple so that it increments the refcount
when it is handed a buffer reference (for symmetry with ExecClearTuple's
decrement of the refcount), and fix about a dozen bugs exposed by these
changes.
I am still getting Buffer Leak notices in the "misc" regression test,
specifically in the queries that invoke more than one SQL function.
What I find there is that SQL functions are not always run to
completion. Apparently, when a function can return multiple tuples,
it won't necessarily be asked to produce them all. And when it isn't,
postquel_end() isn't invoked for the function's current query, so its
tuple table isn't cleared, so we have dangling refcounts if any of the
tuples involved are in disk buffers.
It may be that the save/restore code was a misguided attempt to fix
this problem. I can't tell. But I think what we really need to do is
find some way of ensuring that Postquel function execution contexts
always get shut down by the end of the query, so that they don't leak
resources.
I suppose a straightforward approach would be to keep a list of open
function contexts somewhere (attached to the outer execution context,
perhaps), and clean them up at outer-plan shutdown.
What I am wondering, though, is whether this addition is actually
necessary, or is it a bug that the functions aren't run to completion
in the first place? I don't really understand the semantics of this
"nested dot notation". I suppose it is a Berkeleyism; I can't find
anything about it in the SQL92 document. The test cases shown in the
misc regress test seem peculiar, not to say wrong. For example:
regression=> SELECT p.hobbies.equipment.name, p.hobbies.name, p.name FROM person p;
name |name |name
-------------+-----------+-----
advil |posthacking|mike
peet's coffee|basketball |joe
hightops |basketball |sally
(3 rows)
which doesn't appear to agree with the contents of the underlying
relations:
regression=> SELECT * FROM hobbies_r;
name |person
-----------+------
posthacking|mike
posthacking|jeff
basketball |joe
basketball |sally
skywalking |
(5 rows)
regression=> SELECT * FROM equipment_r;
name |hobby
-------------+-----------
advil |posthacking
peet's coffee|posthacking
hightops |basketball
guts |skywalking
(4 rows)
I'd have expected an output along the lines of
advil |posthacking|mike
peet's coffee|posthacking|mike
hightops |basketball |joe
hightops |basketball |sally
Is the regression test's expected output wrong, or am I misunderstanding
what this query is supposed to do? Is there any documentation anywhere
about how SQL functions returning multiple tuples are supposed to
behave?
regards, tom lane
************
From owner-pgsql-hackers@hub.org Thu Sep 23 11:03:19 1999
Received: from hub.org (hub.org [216.126.84.1])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id LAA16211
for <maillist@candle.pha.pa.us>; Thu, 23 Sep 1999 11:03:17 -0400 (EDT)
Received: from hub.org (hub.org [216.126.84.1])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA58151;
Thu, 23 Sep 1999 10:53:46 -0400 (EDT)
(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Thu, 23 Sep 1999 10:53:05 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id KAA57948
for pgsql-hackers-outgoing; Thu, 23 Sep 1999 10:52:23 -0400 (EDT)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA57841
for <hackers@postgreSQL.org>; Thu, 23 Sep 1999 10:51:50 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
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 KAA14211;
Thu, 23 Sep 1999 10:51:10 -0400 (EDT)
To: Andreas Zeugswetter <andreas.zeugswetter@telecom.at>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] Progress report: buffer refcount bugs and SQL functions
In-reply-to: Your message of Thu, 23 Sep 1999 10:07:24 +0200
<37E9DFBC.5C0978F@telecom.at>
Date: Thu, 23 Sep 1999 10:51:10 -0400
Message-ID: <14209.938098270@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: RO
Andreas Zeugswetter <andreas.zeugswetter@telecom.at> writes:
> That is what I use it for. I have never used it with a
> returns setof function, but reading the comments in the regression test,
> -- mike needs advil and peet's coffee,
> -- joe and sally need hightops, and
> -- everyone else is fine.
> it looks like the results you expected are correct, and currently the
> wrong result is given.
Yes, I have concluded the same (and partially fixed it, per my previous
message).
> Those that don't have a hobbie should return name|NULL|NULL. A hobbie
> that does'nt need equipment name|hobbie|NULL.
That's a good point. Currently (both with and without my uncommitted
fix) you get *no* rows out from ExecTargetList if there are any Iters
that return empty result sets. It might be more reasonable to treat an
empty result set as if it were NULL, which would give the behavior you
suggest.
This would be an easy change to my current patch, and I'm prepared to
make it before committing what I have, if people agree that that's a
more reasonable definition. Comments?
regards, tom lane
************
From owner-pgsql-hackers@hub.org Thu Sep 23 04:31:15 1999
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 EAA11344
for <maillist@candle.pha.pa.us>; Thu, 23 Sep 1999 04:31:15 -0400 (EDT)
Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id EAA05350 for <maillist@candle.pha.pa.us>; Thu, 23 Sep 1999 04:24:29 -0400 (EDT)
Received: from hub.org (hub.org [216.126.84.1])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA85679;
Thu, 23 Sep 1999 04:16:26 -0400 (EDT)
(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Thu, 23 Sep 1999 04:09:52 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id EAA84708
for pgsql-hackers-outgoing; Thu, 23 Sep 1999 04:08:57 -0400 (EDT)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA84632
for <hackers@postgresql.org>; Thu, 23 Sep 1999 04:08:03 -0400 (EDT)
(envelope-from andreas.zeugswetter@telecom.at)
Received: from telecom.at (w0188000580.f000.d0188.sd.spardat.at [172.18.65.249])
by gandalf.telecom.at (xxx/xxx) with ESMTP id KAA195294
for <hackers@postgresql.org>; Thu, 23 Sep 1999 10:07:27 +0200
Message-ID: <37E9DFBC.5C0978F@telecom.at>
Date: Thu, 23 Sep 1999 10:07:24 +0200
From: Andreas Zeugswetter <andreas.zeugswetter@telecom.at>
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: hackers@postgreSQL.org
Subject: Re: [HACKERS] Progress report: buffer refcount bugs and SQL functions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: RO
> Is the regression test's expected output wrong, or am I
> misunderstanding
> what this query is supposed to do? Is there any
> documentation anywhere
> about how SQL functions returning multiple tuples are supposed to
> behave?
They are supposed to behave somewhat like a view.
Not all rows are necessarily fetched.
If used in a context that needs a single row answer,
and the answer has multiple rows it is supposed to
runtime elog. Like in:
select * from tbl where col=funcreturningmultipleresults();
-- this must elog
while this is ok:
select * from tbl where col in (select funcreturningmultipleresults());
But the caller could only fetch the first row if he wanted.
The nested notation is supposed to call the function passing it the tuple
as the first argument. This is what can be used to "fake" a column
onto a table (computed column).
That is what I use it for. I have never used it with a
returns setof function, but reading the comments in the regression test,
-- mike needs advil and peet's coffee,
-- joe and sally need hightops, and
-- everyone else is fine.
it looks like the results you expected are correct, and currently the
wrong result is given.
But I think this query could also elog whithout removing substantial
functionality.
SELECT p.name, p.hobbies.name, p.hobbies.equipment.name FROM person p;
Actually for me it would be intuitive, that this query return one row per
person, but elog on those that have more than one hobbie or a hobbie that
needs more than one equipment. Those that don't have a hobbie should
return name|NULL|NULL. A hobbie that does'nt need equipment name|hobbie|NULL.
Andreas
************
From owner-pgsql-hackers@hub.org Wed Sep 22 22:01:07 1999
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 WAA16360
for <maillist@candle.pha.pa.us>; Wed, 22 Sep 1999 22:01:05 -0400 (EDT)
Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id VAA08386 for <maillist@candle.pha.pa.us>; Wed, 22 Sep 1999 21:37:24 -0400 (EDT)
Received: from hub.org (hub.org [216.126.84.1])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA88083;
Wed, 22 Sep 1999 21:28:11 -0400 (EDT)
(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Wed, 22 Sep 1999 21:27:48 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id VAA87938
for pgsql-hackers-outgoing; Wed, 22 Sep 1999 21:26:52 -0400 (EDT)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de [53.2.131.8])
by hub.org (8.9.3/8.9.3) with SMTP id VAA87909
for <pgsql-hackers@postgresql.org>; Wed, 22 Sep 1999 21:26:36 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de
for pgsql-hackers@postgresql.org
id m11TxXw-0003kLC; Thu, 23 Sep 99 03:19 MET DST
Message-Id: <m11TxXw-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Progress report: buffer refcount bugs and SQL functions
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Thu, 23 Sep 1999 03:19:39 +0200 (MET DST)
Cc: pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <6408.938045139@sss.pgh.pa.us> from "Tom Lane" at Sep 22, 99 08:05:39 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: RO
Tom Lane wrote:
> [...]
>
> What I am wondering, though, is whether this addition is actually
> necessary, or is it a bug that the functions aren't run to completion
> in the first place? I don't really understand the semantics of this
> "nested dot notation". I suppose it is a Berkeleyism; I can't find
> anything about it in the SQL92 document. The test cases shown in the
> misc regress test seem peculiar, not to say wrong. For example:
>
> [...]
>
> Is the regression test's expected output wrong, or am I misunderstanding
> what this query is supposed to do? Is there any documentation anywhere
> about how SQL functions returning multiple tuples are supposed to
> behave?
I've said some time (maybe too long) ago, that SQL functions
returning tuple sets are broken in general. This nested dot
notation (which I think is an artefact from the postquel
querylanguage) is implemented via set functions.
Set functions have total different semantics from all other
functions. First they don't really return a tuple set as
someone might think - all that screwed up code instead
simulates that they return something you could consider a
scan of the last SQL statement in the function. Then, on
each subsequent call inside of the same command, they return
a "tupletable slot" containing the next found tuple (that's
why their Func node is mangled up after the first call).
Second they have a targetlist what I think was originally
intended to extract attributes out of the tuples returned
when the above scan is asked to get the next tuple. But as I
read the code it invokes the function again and this might
cause the resource leakage you see.
Third, all this seems to never have been implemented
(thought?) to the end. A targetlist doesn't make sense at
this place because it could at max contain a single attribute
- so a single attno would have the same power. And if set
functions could appear in the rangetable (FROM clause), than
they would be treated as that and regular Var nodes in the
query would do it.
I think you shouldn't really care for that regression test
and maybe we should disable set functions until we really
implement stored procedures returning sets in the rangetable.
Set functions where planned by Stonebraker's team as
something that today is called stored procedures. But AFAIK
they never reached the useful state because even in Postgres
4.2 you haven't been able to get more than one attribute out
of a set function. It was a feature of the postquel
querylanguage that you could get one attribute from a set
function via
RETRIEVE (attributename(setfuncname()))
While working on the constraint triggers I've came across
another regression test (triggers :-) that's errorneous too.
The funny_dup17 trigger proc executes an INSERT into the same
relation where it get fired for by a previous INSERT. And it
stops this recursion only if it reaches a nesting level of
17, which could only occur if it is fired DURING the
execution of it's own SPI_exec(). After Vadim quouted some
SQL92 definitions about when constraint checks and triggers
are to be executed, I decided to fire regular triggers at the
end of a query too. Thus, there is absolutely no nesting
possible for AFTER triggers resulting in an endless loop.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
************
From owner-pgsql-hackers@hub.org Thu Sep 23 11:01:06 1999
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 LAA16162
for <maillist@candle.pha.pa.us>; Thu, 23 Sep 1999 11:01:04 -0400 (EDT)
Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id KAA28544 for <maillist@candle.pha.pa.us>; Thu, 23 Sep 1999 10:45:54 -0400 (EDT)
Received: from hub.org (hub.org [216.126.84.1])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA52943;
Thu, 23 Sep 1999 10:20:51 -0400 (EDT)
(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Thu, 23 Sep 1999 10:19:58 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id KAA52472
for pgsql-hackers-outgoing; Thu, 23 Sep 1999 10:19:03 -0400 (EDT)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA52431
for <pgsql-hackers@postgresql.org>; Thu, 23 Sep 1999 10:18:47 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
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 KAA13253;
Thu, 23 Sep 1999 10:18:02 -0400 (EDT)
To: wieck@debis.com (Jan Wieck)
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Progress report: buffer refcount bugs and SQL functions
In-reply-to: Your message of Thu, 23 Sep 1999 03:19:39 +0200 (MET DST)
<m11TxXw-0003kLC@orion.SAPserv.Hamburg.dsh.de>
Date: Thu, 23 Sep 1999 10:18:01 -0400
Message-ID: <13251.938096281@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: RO
wieck@debis.com (Jan Wieck) writes:
> Tom Lane wrote:
>> What I am wondering, though, is whether this addition is actually
>> necessary, or is it a bug that the functions aren't run to completion
>> in the first place?
> I've said some time (maybe too long) ago, that SQL functions
> returning tuple sets are broken in general.
Indeed they are. Try this on for size (using the regression database):
SELECT p.name, p.hobbies.equipment.name FROM person p;
SELECT p.hobbies.equipment.name, p.name FROM person p;
You get different result sets!?
The problem in this example is that ExecTargetList returns the isDone
flag from the last targetlist entry, regardless of whether there are
incomplete iterations in previous entries. More generally, the buffer
leak problem that I started with only occurs if some Iter nodes are not
run to completion --- but execQual.c has no mechanism to make sure that
they have all reached completion simultaneously.
What we really need to make functions-returning-sets work properly is
an implementation somewhat like aggregate functions. We need to make
a list of all the Iter nodes present in a targetlist and cycle through
the values returned by each in a methodical fashion (run the rightmost
through its full cycle, then advance the next-to-rightmost one value,
run the rightmost through its cycle again, etc etc). Also there needs
to be an understanding of the hierarchy when an Iter appears in the
arguments of another Iter's function. (You cycle the upper one for
*each* set of arguments created by cycling its sub-Iters.)
I am not particularly interested in working on this feature right now,
since AFAIK it's a Berkeleyism not found in SQL92. What I've done
is to hack ExecTargetList so that it behaves semi-sanely when there's
more than one Iter at the top level of the target list --- it still
doesn't really give the right answer, but at least it will keep
generating tuples until all the Iters are done at the same time.
It happens that that's enough to give correct answers for the examples
shown in the misc regress test. Even when it fails to generate all
the possible combinations, there will be no buffer leaks.
So, I'm going to declare victory and go home ;-). We ought to add a
TODO item along the lines of
* Functions returning sets don't really work right
in hopes that someone will feel like tackling this someday.
regards, tom lane
************

5708
doc/TODO.detail/limit
View File

File diff suppressed because it is too large Load Diff

119
doc/TODO.detail/null
View File

@ -1,119 +0,0 @@
From owner-pgsql-general@hub.org Fri Oct 9 18:22:09 1998
Received: from hub.org (majordom@hub.org [209.47.148.200])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id SAA04220
for <maillist@candle.pha.pa.us>; Fri, 9 Oct 1998 18:22:08 -0400 (EDT)
Received: from localhost (majordom@localhost)
by hub.org (8.8.8/8.8.8) with SMTP id SAA26960;
Fri, 9 Oct 1998 18:18:29 -0400 (EDT)
(envelope-from owner-pgsql-general@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Fri, 09 Oct 1998 18:18:07 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.8.8/8.8.8) id SAA26917
for pgsql-general-outgoing; Fri, 9 Oct 1998 18:18:04 -0400 (EDT)
(envelope-from owner-pgsql-general@postgreSQL.org)
X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-general@postgreSQL.org using -f
Received: from gecko.statsol.com (gecko.statsol.com [198.11.51.133])
by hub.org (8.8.8/8.8.8) with ESMTP id SAA26904
for <pgsql-general@postgresql.org>; Fri, 9 Oct 1998 18:17:46 -0400 (EDT)
(envelope-from statsol@statsol.com)
Received: from gecko (gecko [198.11.51.133])
by gecko.statsol.com (8.9.0/8.9.0) with SMTP id SAA00557
for <pgsql-general@postgresql.org>; Fri, 9 Oct 1998 18:18:00 -0400 (EDT)
Date: Fri, 9 Oct 1998 18:18:00 -0400 (EDT)
From: Steve Doliov <statsol@statsol.com>
X-Sender: statsol@gecko
To: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Making NULLs visible.
Message-ID: <Pine.GSO.3.96.981009181716.545B-100000@gecko>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pgsql-general@postgreSQL.org
Precedence: bulk
Status: RO
On Fri, 9 Oct 1998, Bruce Momjian wrote:
> [Charset iso-8859-1 unsupported, filtering to ASCII...]
> > > Yes, \ always outputs as \\, excepts someone changed it last week, and I
> > > am requesting a reversal. Do you like the \N if it is unique?
> >
> > Well, it's certainly clear, but could be confused with \n (newline). Can we
> > have \0 instead?
>
> Yes, but it is uppercase. \0 looks like an octal number to me, and I
> think we even output octals sometimes, don't we?
>
my first suggestion may have been hare-brained, but why not just make the
specifics of the output user-configurable. So if the user chooses \0, so
be it, if the user chooses \N so be it, if the user likes NULL so be it.
but the option would only have one value per database at any given point
in time. so database x could use \N on tuesday and NULL on wednesday, but
database x could never have two references to the characters(s) used to
represent a null value.
steve
From owner-pgsql-general@hub.org Sun Oct 11 17:31:08 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 RAA20043
for <maillist@candle.pha.pa.us>; Sun, 11 Oct 1998 17:31:02 -0400 (EDT)
Received: from hub.org (majordom@hub.org [209.47.148.200]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id RAA03069 for <maillist@candle.pha.pa.us>; Sun, 11 Oct 1998 17:10:34 -0400 (EDT)
Received: from localhost (majordom@localhost)
by hub.org (8.8.8/8.8.8) with SMTP id QAA10856;
Sun, 11 Oct 1998 16:57:34 -0400 (EDT)
(envelope-from owner-pgsql-general@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sun, 11 Oct 1998 16:53:35 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.8.8/8.8.8) id QAA10393
for pgsql-general-outgoing; Sun, 11 Oct 1998 16:53:34 -0400 (EDT)
(envelope-from owner-pgsql-general@postgreSQL.org)
X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-general@postgreSQL.org using -f
Received: from mail1.panix.com (mail1.panix.com [166.84.0.212])
by hub.org (8.8.8/8.8.8) with ESMTP id QAA10378
for <pgsql-general@postgreSQL.org>; Sun, 11 Oct 1998 16:53:28 -0400 (EDT)
(envelope-from tomg@admin.nrnet.org)
Received: from mailhost.nrnet.org (root@mailhost.nrnet.org [166.84.192.39])
by mail1.panix.com (8.8.8/8.8.8/PanixM1.3) with ESMTP id QAA16311
for <pgsql-general@postgreSQL.org>; Sun, 11 Oct 1998 16:53:24 -0400 (EDT)
Received: from admin.nrnet.org (uucp@localhost)
by mailhost.nrnet.org (8.8.7/8.8.4) with UUCP
id QAA16345 for pgsql-general@postgreSQL.org; Sun, 11 Oct 1998 16:28:47 -0400
Received: from localhost (tomg@localhost)
by admin.nrnet.org (8.8.7/8.8.7) with SMTP id QAA11569
for <pgsql-general@postgreSQL.org>; Sun, 11 Oct 1998 16:28:41 -0400
Date: Sun, 11 Oct 1998 16:28:41 -0400 (EDT)
From: Thomas Good <tomg@admin.nrnet.org>
To: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] Making NULLs visible.
In-Reply-To: <Pine.GSO.3.96.981009181716.545B-100000@gecko>
Message-ID: <Pine.LNX.3.96.981011161908.11556A-100000@admin.nrnet.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pgsql-general@postgreSQL.org
Precedence: bulk
Status: RO
Watching all this go by...as a guy who has to move alot of data
from legacy dbs to postgres, I've gotten used to \N being a null.
My vote, if I were allowed to cast one, would be to have one null
and that would be the COPY command null. I have no difficulty
distinguishing a null from a newline...
At the pgsql command prompt I would find seeing \N rather reassuring.
I've seen alot of these little guys.
---------- Sisters of Charity Medical Center ----------
Department of Psychiatry
----
Thomas Good <tomg@q8.nrnet.org>
Coordinator, North Richmond C.M.H.C. Information Systems
75 Vanderbilt Ave, Quarters 8 Phone: 718-354-5528
Staten Island, NY 10304 Fax: 718-354-5056

55
doc/TODO.detail/pg_shadow
View File

@ -1,55 +0,0 @@
From owner-pgsql-hackers@hub.org Sun Aug 2 20:01:13 1998
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id UAA15937
for <maillist@candle.pha.pa.us>; Sun, 2 Aug 1998 20:01:11 -0400 (EDT)
Received: from hub.org (hub.org [209.47.148.200]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id TAA01026 for <maillist@candle.pha.pa.us>; Sun, 2 Aug 1998 19:33:53 -0400 (EDT)
Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id TAA19878; Sun, 2 Aug 1998 19:30:59 -0400 (EDT)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sun, 02 Aug 1998 19:28:23 +0000 (EDT)
Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id TAA19534 for pgsql-hackers-outgoing; Sun, 2 Aug 1998 19:28:22 -0400 (EDT)
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [206.210.65.6]) by hub.org (8.8.8/8.7.5) with ESMTP id TAA19521 for <pgsql-hackers@postgreSQL.org>; Sun, 2 Aug 1998 19:28:15 -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 TAA22594
for <pgsql-hackers@postgreSQL.org>; Sun, 2 Aug 1998 19:28:13 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] TODO item: make pg_shadow updates more robust
Date: Sun, 02 Aug 1998 19:28:13 -0400
Message-ID: <22591.902100493@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Sender: owner-pgsql-hackers@hub.org
Precedence: bulk
Status: ROr
I learned the hard way last night that the postmaster's password
authentication routines don't look at the pg_shadow table. They
look at a separate file named pg_pwd, which certain backend operations
will update from pg_shadow. (This is not documented in any user
documentation that I could find; I had to burrow into
src/backend/commands/user.c to discover it.)
Unfortunately, if a clueless dbadmin (like me ;-)) tries to update
password data with the obvious thing,
update pg_shadow set passwd = 'xxxxx' where usename = 'yyyy';
pg_pwd doesn't get fixed.
A more drastic problem is that pg_dump believes it can save and
restore pg_shadow data using "copy". Following an initdb and restore
from a pg_dump -z script, pg_shadow will look just fine, but only
the database admin will be listed in pg_pwd. This is likely to provoke
some confusion, IMHO.
As a short-term thing, the fact that you *must* set passwords with
ALTER USER ought to be documented, preferably someplace where a
dbadmin who's never heard of ALTER USER is likely to find it.
As a longer-term thing, I think it would be far better if ordinary
SQL operations on pg_shadow just did the right thing. Wouldn't it
be possible to implement copying to pg_pwd by means of a trigger on
pg_shadow updates, or something like that?
(I'm afraid that pg_dump -z is pretty well broken for operations on
a password-protected database, btw. Has anyone used it successfully
in that situation?)
regards, tom lane

805
doc/TODO.detail/primary
View File

@ -1,805 +0,0 @@
From owner-pgsql-hackers@hub.org Fri Sep 4 00:47:06 1998
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id AAA01047
for <maillist@candle.pha.pa.us>; Fri, 4 Sep 1998 00:47:05 -0400 (EDT)
Received: from hub.org (hub.org [209.47.148.200]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id XAA02044 for <maillist@candle.pha.pa.us>; Thu, 3 Sep 1998 23:11:07 -0400 (EDT)
Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id XAA27418; Thu, 3 Sep 1998 23:06:16 -0400 (EDT)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Thu, 03 Sep 1998 23:04:11 +0000 (EDT)
Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id XAA27185 for pgsql-hackers-outgoing; Thu, 3 Sep 1998 23:04:09 -0400 (EDT)
Received: from dune.krs.ru (dune.krs.ru [195.161.16.38]) by hub.org (8.8.8/8.7.5) with ESMTP id XAA27169 for <hackers@postgreSQL.org>; Thu, 3 Sep 1998 23:03:59 -0400 (EDT)
Received: from krs.ru (localhost.krs.ru [127.0.0.1])
by dune.krs.ru (8.8.8/8.8.8) with ESMTP id LAA10059;
Fri, 4 Sep 1998 11:03:00 +0800 (KRSS)
(envelope-from vadim@krs.ru)
Message-ID: <35EF5864.E5142D35@krs.ru>
Date: Fri, 04 Sep 1998 11:03:00 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386)
MIME-Version: 1.0
To: "D'Arcy J.M. Cain" <darcy@druid.net>
CC: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>, hackers@postgreSQL.org
Subject: Re: [HACKERS] Adding PRIMARY KEY info
References: <m0zEaoV-00006JC@druid.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pgsql-hackers@hub.org
Precedence: bulk
Status: RO
D'Arcy J.M. Cain wrote:
>
> Thus spake Vadim Mikheev
> > Imho, indices should be used/created for FOREIGN keys and so pg_index
> > is good place for both PRIMARY and FOREIGN keys infos.
>
> Are you sure? I don't know about implementing it but it seems more
> like an attribute thing rather than an index thing. Certainly from a
> database design viewpoint you want to refer to the fields, not the
> index on them. If you put it into the index then you have to do
> an extra join to get the information.
>
> Perhaps you have to do the extra join anyway for other purposes so it
> may not matter. All I want is to be able to be able to extract the
> field that the designer specified as the key. As long as I can design
> a select statement that gives me that I don't much care how it is
> implemented. I'll cache the information anyway so it won't have a
> huge impact on my programs.
First, let me note that you have to add int28 field to pg_class,
not just oid field, to know what attributeS are in primary key
(we support multi-attribute primary keys).
This could be done...
But what about foreign and unique (!) keys ?
There may be _many_ foreign/unique keys defined for one table!
And so foreign/unique keys info have to be stored somewhere else,
not in pg_class.
pg_index is good place for all _3_ key types because of:
1. index should be created for each foreign key -
just for performance.
2. pg_index already has int28 field for key attributes.
3. pg_index already has indisunique (note that foreign keys
may reference unique keys, not just primary ones).
- so we have just add two fields to pg_index:
bool indisprimary;
oid indreferenced;
^^^^^^^^^^^^^^^^^^
this is for foreign keys: oid of referenced relation'
primary/unique key index.
I agreed that indices are just implementation...
If you don't like to store key infos in pg_index then
new pg_key relation have to be added...
Comments ?
Vadim
From owner-pgsql-hackers@hub.org Sat Sep 5 02:01:13 1998
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
by candle.pha.pa.us (8.8.5/8.8.5) with ESMTP id CAA14437
for <maillist@candle.pha.pa.us>; Sat, 5 Sep 1998 02:01:11 -0400 (EDT)
Received: from hub.org (hub.org [209.47.148.200]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id BAA09928 for <maillist@candle.pha.pa.us>; Sat, 5 Sep 1998 01:48:32 -0400 (EDT)
Received: from localhost (majordom@localhost) by hub.org (8.8.8/8.7.5) with SMTP id BAA18282; Sat, 5 Sep 1998 01:43:16 -0400 (EDT)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Sat, 05 Sep 1998 01:41:40 +0000 (EDT)
Received: (from majordom@localhost) by hub.org (8.8.8/8.7.5) id BAA18241 for pgsql-hackers-outgoing; Sat, 5 Sep 1998 01:41:38 -0400 (EDT)
Received: from dune.krs.ru (dune.krs.ru [195.161.16.38]) by hub.org (8.8.8/8.7.5) with ESMTP id BAA18211; Sat, 5 Sep 1998 01:41:21 -0400 (EDT)
Received: from krs.ru (localhost.krs.ru [127.0.0.1])
by dune.krs.ru (8.8.8/8.8.8) with ESMTP id NAA20555;
Sat, 5 Sep 1998 13:40:44 +0800 (KRSS)
(envelope-from vadim@krs.ru)
Message-ID: <35F0CEDB.AD721090@krs.ru>
Date: Sat, 05 Sep 1998 13:40:43 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.05 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386)
MIME-Version: 1.0
To: "D'Arcy J.M. Cain" <darcy@druid.net>
CC: hackers@postgreSQL.org, pgsql-core@postgreSQL.org
Subject: Re: [HACKERS] Adding PRIMARY KEY info
References: <m0zEvLK-00006FC@druid.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pgsql-hackers@hub.org
Precedence: bulk
Status: ROr
D'Arcy J.M. Cain wrote:
>
> >
> > pg_index is good place for all _3_ key types because of:
> >
> > 1. index should be created for each foreign key -
> > just for performance.
> > 2. pg_index already has int28 field for key attributes.
> > 3. pg_index already has indisunique (note that foreign keys
> > may reference unique keys, not just primary ones).
> >
> > - so we have just add two fields to pg_index:
> >
> > bool indisprimary;
> > oid indreferenced;
> > ^^^^^^^^^^^^^^^^^^
> > this is for foreign keys: oid of referenced relation'
> > primary/unique key index.
>
> Sounds fine to me. Any chance of seeing this in 6.4?
I could add this (and FOREIGN key implementation) before
11-13 Sep... But not the ALTER TABLE ADD/DROP CONSTRAINT
stuff (ok for Entry SQL).
But we are in beta...
Comments?
> Nope, pg_index is fine by me. Now, once we have this, how do we find
> the index for a particular attribute? I can't seem to figure out the
> relationship between pg_attribute and pg_index. The chart in the docs
> suggests that indkey is the relation but I can't see any useful info
> there for joining the tables.
pg_index:
indrelid - oid of indexed relation
indkey - up to the 8 attnums
pg_attribute:
attrelid - oid of relation
attnum - ...
Without outer join you have to query pg_attribute for each
valid attnum from pg_index->indkey -:(
Vadim
From owner-pgsql-hackers@hub.org Tue Sep 21 05:31:11 1999
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 FAA07543
for <maillist@candle.pha.pa.us>; Tue, 21 Sep 1999 05:31:09 -0400 (EDT)
Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id FAA19587 for <maillist@candle.pha.pa.us>; Tue, 21 Sep 1999 05:12:03 -0400 (EDT)
Received: from hub.org (hub.org [216.126.84.1])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA55119;
Tue, 21 Sep 1999 04:48:48 -0400 (EDT)
(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Tue, 21 Sep 1999 04:45:33 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id EAA54532
for pgsql-hackers-outgoing; Tue, 21 Sep 1999 04:44:35 -0400 (EDT)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de [53.2.131.8])
by hub.org (8.9.3/8.9.3) with SMTP id EAA54496
for <pgsql-hackers@postgreSQL.org>; Tue, 21 Sep 1999 04:44:13 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de
for pgsql-hackers@postgreSQL.org
id m11TLQP-0003kLC; Tue, 21 Sep 99 10:37 MET DST
Message-Id: <m11TLQP-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: [HACKERS] Re: Referential Integrity In PostgreSQL
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Date: Tue, 21 Sep 1999 10:37:21 +0200 (MET DST)
Reply-To: wieck@debis.com (Jan Wieck)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: RO
>
> Hi , Jan
>
> my name is Max .
Hi Max,
>
> I have contributed to SPI interface ,
> that with external Trigger try to make
> a referential integrity.
>
> If I can Help , in something ,
> I'm here .
>
You're welcome.
I've CC'd the hackers list because we might get some ideas
from there too (and to surface once in a while - Bruce
already missed me).
Currently I'm very busy for serious work so I don't find
enough spare time to start on such a big change to
PostgreSQL. But I'd like to give you an overview of what I
have in mind so far so you can decide if you're able to help.
Referential integrity (RI) is based on constraints defined in
the schema of a database. There are some different types of
constraints:
1. Uniqueness constraints.
2. Foreign key constraints that ensure that a key value used
in an attribute exists in another relation. One
constraint must ensure you're unable to INSERT/UPDATE to
a value that doesn't exist, another one must prevent
DELETE on a referenced key item or that it is changed
during UPDATE.
3. Cascading deletes that let rows referring to a key follow
on DELETE silently.
Even if not defined in the standard (AFAIK) there could be
others like letting references automatically follow on UPDATE
to a key value.
All constraints can be enabled and/or default to be deferred.
That means, that the RI checks aren't performed when they are
triggerd. Instead, they're checked at transaction end or if
explicitly invoked by some special statement. This is really
important because someone must be able to setup cyclic RI
checks that could never be satisfied if the checks would be
performed immediately. The major problem on this is the
amount of data affected until the checks must be performed.
The number of statements executed, that trigger such deferred
constraints, shouldn't be limited. And one single
INSERT/UPDATE/DELETE could affect thousands of rows.
Due to these problems I thought, it might not be such a good
idea to remember CTID's or the like to get back OLD/NEW rows
at the time the constraints are checked. Instead I planned to
misuse the rule system for it. Unfortunately, the rule system
has damned tricky problems itself when it comes to having-,
distinct and other clauses and extremely on aggregates and
subselects. These problems would have to get fixed first. So
it's a solution that cannot be implemented right now.
Fallback to CTID remembering though. There are problems too
:-(. Let's enhance the trigger mechanism with a deferred
feature. First this requires two additional bool attributes
in the pg_trigger relation that tell if this trigger is
deferrable and if it is deferred by default. While at it we
should add another bool that tells if the trigger is enabled
(ALTER TRIGGER {ENABLE|DISABLE} trigger).
Second we need an internal list of triggers, that are
currently DEFINED AS DEFERRED. Either because they default to
it, or the user explicitly asked to deferr it.
Third we need an internal list of triggers that must be
invoked later because at the time an event occured where they
should have been triggered, they appeared in the other list
and their execution is delayed until transaction end or
explicit execution. This list must remember the OID of the
trigger to invoke (to identify the procedure and the
arguments), the relation that caused the trigger and the
CTID's of the OLD and NEW row.
That last list could grow extremely! Think of a trigger
that's executing commands over SPI which in turn activate
deferred triggers. Since the order of trigger execution is
very important for RI, I can't see any chance to
simplify/condense this information. Thus it is 16 bytes at
least per deferred trigger call (2 OID's plus 2 CTID's). I
think one or more temp files would fit best for this.
A last tricky point is if one of a bunch of deferred triggers
is explicitly called for execution. At this time, the entries
for it in the temp file(s) must get processed and marked
executed (maybe by overwriting the triggers OID with the
invalid OID) while other trigger events still have to get
recorded.
Needless to say that reading thousands of those entries just
to find a few isn't good on performance. But better have this
special case slow that dealing with hundreds of temp files or
other overhead slowing down the usual case where ALL deferred
triggers get called at transaction end.
Trigger invocation is simple now - fetch the OLD and NEW rows
by CTID and execute the trigger as done by the trigger
manager. Oh - well - vacuum shouldn't touch relations where
deferred triggers are outstanding. Might require some
special lock entry - Vadim?
Did I miss something?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
************
From owner-pgsql-hackers@hub.org Tue Sep 21 08:31:03 1999
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 IAA09071
for <maillist@candle.pha.pa.us>; Tue, 21 Sep 1999 08:31:02 -0400 (EDT)
Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id IAA25991 for <maillist@candle.pha.pa.us>; Tue, 21 Sep 1999 08:04:59 -0400 (EDT)
Received: from hub.org (hub.org [216.126.84.1])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA82019;
Tue, 21 Sep 1999 07:48:14 -0400 (EDT)
(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Tue, 21 Sep 1999 07:47:30 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id HAA81906
for pgsql-hackers-outgoing; Tue, 21 Sep 1999 07:46:38 -0400 (EDT)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de [53.2.131.8])
by hub.org (8.9.3/8.9.3) with SMTP id HAA81888
for <hackers@postgreSQL.org>; Tue, 21 Sep 1999 07:46:26 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de
for hackers@postgreSQL.org
id m11TOGd-0003kwC; Tue, 21 Sep 99 13:39 MET DST
Message-Id: <m11TOGd-0003kwC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Re: Referential Integrity In PostgreSQL
To: andreas.zeugswetter@telecom.at (Andreas Zeugswetter)
Date: Tue, 21 Sep 1999 13:39:27 +0200 (MET DST)
Cc: hackers@postgresql.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37E74EB9.44F9766E@telecom.at> from "Andreas Zeugswetter" at Sep 21, 99 11:24:09 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Sender: owner-pgsql-hackers@postgresql.org
Precedence: bulk
Status: RO
>
> > Oh - well - vacuum shouldn't touch relations where
> > deferred triggers are outstanding. Might require some
> > special lock entry - Vadim?
>
> All modified data will be in this same still open transaction.
> Therefore no relevant data can be removed by vacuum anyway.
I expect this, but I really need to be sure that not even the
location of the tuple in the heap will change. I need to find
the tuples at the time the deferred triggers must be executed
via heap_fetch() by their CTID!
>
> It is my understanding, that the RI check is performed on the newest
> available (committed) data (+ modified data from my own tx).
> E.g. a primary key that has been removed by another transaction after
> my begin work will lead to an RI violation if referenced as foreign key.
Absolutely right. The function that will fire the deferred
triggers must switch to READ COMMITTED isolevel while doing
so.
What I'm not sure about is which snapshot to use to get the
OLD tuples (outdated in this transaction by a previous
command). Vadim?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
************
From owner-pgsql-hackers@hub.org Tue Sep 21 10:45:40 1999
Received: from hub.org (hub.org [216.126.84.1])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id KAA10993
for <maillist@candle.pha.pa.us>; Tue, 21 Sep 1999 10:45:39 -0400 (EDT)
Received: from hub.org (hub.org [216.126.84.1])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA22590;
Tue, 21 Sep 1999 10:36:16 -0400 (EDT)
(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Tue, 21 Sep 1999 10:35:37 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id KAA22200
for pgsql-hackers-outgoing; Tue, 21 Sep 1999 10:34:47 -0400 (EDT)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA22048
for <hackers@postgreSQL.org>; Tue, 21 Sep 1999 10:33:38 -0400 (EDT)
(envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id WAA27122;
Tue, 21 Sep 1999 22:33:22 +0800 (KRSS)
Message-ID: <37E79730.CC415030@krs.ru>
Date: Tue, 21 Sep 1999 22:33:20 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Jan Wieck <wieck@debis.com>
CC: Andreas Zeugswetter <andreas.zeugswetter@telecom.at>,
hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Referential Integrity In PostgreSQL
References: <m11TOGd-0003kwC@orion.SAPserv.Hamburg.dsh.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: RO
Jan Wieck wrote:
>
> > It is my understanding, that the RI check is performed on the newest
> > available (committed) data (+ modified data from my own tx).
> > E.g. a primary key that has been removed by another transaction after
> > my begin work will lead to an RI violation if referenced as foreign key.
>
> Absolutely right. The function that will fire the deferred
> triggers must switch to READ COMMITTED isolevel while doing
^^^^^^^^^^^^^^
> so.
NO!
What if one transaction deleted PK, another one inserted FK
and now both performe RI check? Both transactions _must_
use DIRTY READs to notice that RI violated by another
in-progress transaction and wait for concurrent transaction...
BTW, using triggers to check _each_ modified tuple
(i.e. run Executor for each modified tuple) is bad for
performance. We could implement direct support for
standard RI constraints.
Using rules (statement level triggers) for INSERT...SELECT,
UPDATE and DELETE queries would be nice! Actually, RI constraint
checks need in very simple queries (i.e. without distinct etc)
and the only we would have to do is
> What I'm not sure about is which snapshot to use to get the
> OLD tuples (outdated in this transaction by a previous
> command). Vadim?
1. Add CommandId to Snapshot.
2. Use Snapshot->CommandId instead of global CurrentScanCommandId.
3. Use Snapshots with different CommandId-s to get OLD/NEW
versions.
But I agreed that the size of parsetrees may be big and for
COPY...FROM/INSERTs we should remember IDs of modified
tuples. Well. Please remember that I implement WAL right
now, already have 1000 lines of code and hope to run first
tests after writing additional ~200 lines -:)
We could read modified tuple IDs from WAL...
Vadim
************
From owner-pgsql-hackers@hub.org Tue Sep 21 11:18:19 1999
Received: from hub.org (hub.org [216.126.84.1])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id LAA11537
for <maillist@candle.pha.pa.us>; Tue, 21 Sep 1999 11:18:18 -0400 (EDT)
Received: from hub.org (hub.org [216.126.84.1])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA27395;
Tue, 21 Sep 1999 11:04:42 -0400 (EDT)
(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Tue, 21 Sep 1999 11:03:56 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id LAA27106
for pgsql-hackers-outgoing; Tue, 21 Sep 1999 11:02:50 -0400 (EDT)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de [53.2.131.8])
by hub.org (8.9.3/8.9.3) with SMTP id LAA27041
for <hackers@postgreSQL.org>; Tue, 21 Sep 1999 11:02:34 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de
for hackers@postgreSQL.org
id m11TRKP-0003kLC; Tue, 21 Sep 99 16:55 MET DST
Message-Id: <m11TRKP-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Re: Referential Integrity In PostgreSQL
To: vadim@krs.ru (Vadim Mikheev)
Date: Tue, 21 Sep 1999 16:55:33 +0200 (MET DST)
Cc: wieck@debis.com, andreas.zeugswetter@telecom.at, hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37E79730.CC415030@krs.ru> from "Vadim Mikheev" at Sep 21, 99 10:33:20 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: RO
>
> Jan Wieck wrote:
> >
> > > It is my understanding, that the RI check is performed on the newest
> > > available (committed) data (+ modified data from my own tx).
> > > E.g. a primary key that has been removed by another transaction after
> > > my begin work will lead to an RI violation if referenced as foreign key.
> >
> > Absolutely right. The function that will fire the deferred
> > triggers must switch to READ COMMITTED isolevel while doing
> ^^^^^^^^^^^^^^
> > so.
>
> NO!
> What if one transaction deleted PK, another one inserted FK
> and now both performe RI check? Both transactions _must_
> use DIRTY READs to notice that RI violated by another
> in-progress transaction and wait for concurrent transaction...
Oh - I see - yes.
>
> BTW, using triggers to check _each_ modified tuple
> (i.e. run Executor for each modified tuple) is bad for
> performance. We could implement direct support for
> standard RI constraints.
As I want to implement it, there would be not much difference
between a regular trigger invocation and a deferred one. If
that causes a performance problem, I think we should speed up
the trigger call mechanism in general instead of not using
triggers.
>
> Using rules (statement level triggers) for INSERT...SELECT,
> UPDATE and DELETE queries would be nice! Actually, RI constraint
> checks need in very simple queries (i.e. without distinct etc)
> and the only we would have to do is
>
> > What I'm not sure about is which snapshot to use to get the
> > OLD tuples (outdated in this transaction by a previous
> > command). Vadim?
>
> 1. Add CommandId to Snapshot.
> 2. Use Snapshot->CommandId instead of global CurrentScanCommandId.
> 3. Use Snapshots with different CommandId-s to get OLD/NEW
> versions.
>
> But I agreed that the size of parsetrees may be big and for
> COPY...FROM/INSERTs we should remember IDs of modified
> tuples. Well. Please remember that I implement WAL right
> now, already have 1000 lines of code and hope to run first
> tests after writing additional ~200 lines -:)
> We could read modified tuple IDs from WAL...
Not only on COPY. One regular INSERT/UPDATE/DELETE statement
can actually fire thousands of trigger calls right now. These
triggers normally use SPI to execute their own queries. If
such a trigger now uses a query that in turn causes a
deferred constraint, we might have to save thousands of
deferred querytrees - impossible mission.
That's IMHO a clear drawback against using rules for
deferrable RI.
What I'm currently doing is clearly encapsulated in some
functions in commands/trigger.c (except for some additional
attributes in pg_trigger). If it later turns out that we can
combine the information required into WAL, I think we have
time enough to do so and shouldn't really care if v6.6
doesn't have it already combined.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
************
From owner-pgsql-hackers@hub.org Tue Sep 21 15:30:29 1999
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 PAA14590
for <maillist@candle.pha.pa.us>; Tue, 21 Sep 1999 15:30:28 -0400 (EDT)
Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$ Revision: 1.18 $) with ESMTP id PAA09192 for <maillist@candle.pha.pa.us>; Tue, 21 Sep 1999 15:06:09 -0400 (EDT)
Received: from hub.org (hub.org [216.126.84.1])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA73126;
Tue, 21 Sep 1999 14:56:15 -0400 (EDT)
(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Tue, 21 Sep 1999 14:54:47 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id OAA72607
for pgsql-hackers-outgoing; Tue, 21 Sep 1999 14:53:51 -0400 (EDT)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de [53.2.131.8])
by hub.org (8.9.3/8.9.3) with SMTP id OAA72516
for <pgsql-hackers@postgreSQL.org>; Tue, 21 Sep 1999 14:52:56 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de
for pgsql-hackers@postgreSQL.org
id m11TUvX-0003kLC; Tue, 21 Sep 99 20:46 MET DST
Message-Id: <m11TUvX-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: [HACKERS] RI question
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Date: Tue, 21 Sep 1999 20:46:06 +0200 (MET DST)
Reply-To: wieck@debis.com (Jan Wieck)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: RO
Uh oh,
I think deferred RI constraints must only fire the actions
that remain after all commands during the entire transaction
are condensed to the total minimum required to get that
state, because deferred RI must only check what VISIBLY
happened during the transaction.
Thinking on the tuple level, a sequence of
INSERT,UPDATE,UPDATE must fire only one INSERT trigger, but
with the values of the last UPDATE. An UPDATE,DELETE sequence
is in fact a DELETE of the original tuple and an
INSERT,UPDATE,DELETE sequence is nothing.
That means that the recording mechnism of the trigger events
must be very smart on UPDATE and DELETE events, looking at
the x_min of the old tuple if that resulted from the current
transaction. If so, follow the events backward, disable
previous ones and change the new event into what it really
has to be.
But some problems remain unsolvable by this:
- PK has an ON DELETE CASCADE for FK
- BEGIN
- DELETE PK
- INSERT same PK
- COMMIT.
This really shouldn't invoke the cascading delete, because at
COMMIT the PK still is there. Same for a constraint that
forbids deletion of a PK while referenced by FK. Therefore
the deferred event recorder must check on INSERT any previous
DELETES for the same relation if the key does match and drop
both deferred triggers if so. Therefore it needs to know
which attributes build the PK of that relation
(<relname>_pkey guaranteed?).
Well, I think that's finally the death of RI over rules. The
code managing those rules during CREATE/ALTER TABLE would
become totally unmaintainable. And (sorry Vadim) it's the
death of SLT for this too because this event tracking must be
done on the tuple level.
It complicated the trigger approach too, but IMHO not too
bad. Anyway, some co-developer(s) doing the parser- and
utility-statement stuff (SET CONSTRAINTS ... etc.) would be
great.
Volunteers?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
************
From owner-pgsql-hackers@hub.org Tue Jul 13 22:30:50 1999
Received: from hub.org (hub.org [209.167.229.1])
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id WAA08452
for <maillist@candle.pha.pa.us>; Tue, 13 Jul 1999 22:30:49 -0400 (EDT)
Received: from hub.org (hub.org [209.167.229.1])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA31614;
Tue, 13 Jul 1999 22:25:04 -0400 (EDT)
(envelope-from owner-pgsql-hackers@hub.org)
Received: by hub.org (TLB v0.10a (1.23 tibbs 1997/01/09 00:29:32)); Tue, 13 Jul 1999 22:22:59 +0000 (EDT)
Received: (from majordom@localhost)
by hub.org (8.9.3/8.9.3) id WAA31285
for pgsql-hackers-outgoing; Tue, 13 Jul 1999 22:22:58 -0400 (EDT)
(envelope-from owner-pgsql-hackers@postgreSQL.org)
X-Authentication-Warning: hub.org: majordom set sender to owner-pgsql-hackers@postgreSQL.org using -f
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA31259
for <pgsql-hackers@postgreSQL.org>; Tue, 13 Jul 1999 22:22:47 -0400 (EDT)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id LAA04296 for <pgsql-hackers@postgreSQL.org>; Wed, 14 Jul 1999 11:22:46 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
Subject: [HACKERS] 9-key index ?
Date: Wed, 14 Jul 1999 11:25:09 +0900
Message-ID: <000401becda0$17deee60$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Sender: owner-pgsql-hackers@postgreSQL.org
Precedence: bulk
Status: RO
Hi all,
I could create a 9-key index.
create table ix9 (
i1 int4,
i2 int4,
i3 int4,
i4 int4,
i5 int4,
i6 int4,
i7 int4,
i8 int4,
i9 int4,
primary key (i1,i2,i3,i4,i5,i6,i7,i8,i9)
);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index 'ix9_pkey'
for table 'ix9'
CREATE
\d ix9_pkey
Table = ix9_pkey
+----------------------------------+----------------------------------+-----
--+
| Field | Type |
Length|
+----------------------------------+----------------------------------+-----
--+
| i1 | int4 |
4 |
| i2 | int4 |
4 |
| i3 | int4 |
4 |
| i4 | int4 |
4 |
| i5 | int4 |
4 |
| i6 | int4 |
4 |
| i7 | int4 |
4 |
| i8 | int4 |
4 |
| i9 | int4 |
4 |
+----------------------------------+----------------------------------+-----
--+
Is it right ?
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp