Re: [HACKERS] CVS should die (was: Possible make_oidjoins_check ...)
The intuitive understanding of a file is certainly something like a file called 'baz.c' residing at 'foo/bar/', which contains the BAZ subsystem. Now, when renaming/moving a file such an intuitive understanding is partially lost. UI-wise that's a problem which I haven't ever seen solved well. However, other SCM systems such as Subversion and Continuus (and our to-be-released system Maint, and certainly others) treat files as unique entities unrelated to their path, and thus don't have problems with moves. With regards to modes of working this, it boils down to two methods. One is treating directories as first class entities (opposed to CVS which treats dirs as semi-relevant appendices to real files), versioned to contain a list of children, or simpler yet, to store the parent directory as an meaningful attribute of an object. Both methods have their pros and cons, the latter is somehow simpler to intuitively grasp for people. This doesn't really answer the question of what tool Postgres might change to, but it seems that Subversion is a good tool one should consider. And by golly, CVS is bad. Just consider the cons having to forbid renames in all but the most necessary cases it just invites cruft into any project. d. -- David Helgason, Business Development et al., Over the Edge I/S (http://otee.dk) Direct line +45 2620 0663 Main line +45 3264 5049 On 4. nov 2004, at 20:41, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: why would we lose CVS history? I can physically move the files in /cvsroot to accomplish this ... just tell me what needs to move, and to where ... If you physically move the files, that would retroactively change their placement in back versions, no? ie, it would appear that all previous releases had had 'em under src/tools as well. AFAICS the only nondestructive way to do this is to cvs delete and cvs add, with a commit comment saying where the files were moved from. Then when you are looking at them in CVS, you'd have to navigate over to the previous location (by hand, probably; the commit comment isn't going to automate this for you) and look in the Attic to read the prior CVS history. It's not impossible, certainly, but it discourages moving files for less than the very best of reasons. (I'm rather interested to know whether any other SCMs have a better solution to this problem, and if so what it is. It's not obvious how to do better.) regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] plperl Safe restrictions
On 14. okt 2004, at 21:09, Andrew Dunstan wrote: It has just been brought to my attention that we are being very restrictive about what we allow to be done in trusted plperl. Basically we allow the :default and :base_math set of operations (run perldoc Opcode or see http://www.perldoc.com/perl5.8.0/lib/Opcode.html for details of what these mean). In particular, we do not allow calls to perl's builtin sort, which is unpleasant, and on reviewing the list it seems to me we could quite reasonably allow access to pack and unpack also. bless and sprintf are also likely candidates for inclusion - I have not finished reviewing the list, and would welcome advice from perl gurus on this. pack and unpack are unfortunately not safe. Very useful, but they allow write/read access to random memory. It's really a shame perl doesn't have a pragma to make them safe or have safe versions of them. Bless should be OK, unless sensitive objects are provided to the procedures. A postgres question I don't know the answer to is whether allowing the user to trigger a segfault is a security problem. If it isn't, several opcodes may probably be allowed, including sort and sprintf. If it is, well, you need only follow the perl5-porters list to know that there's banal perl structures are continuously being found that will segfault perl, some at compile time, other at runtime. On the other side, I think we should exclude the :base_io set which is part of the :default set (we don't want trusted plperl writing to stdout, for example - all IO should be forbidden). Definitely out :) I know changing this at this stage of the dev cycle is bad, but I think it ought to be done. Unless there are loud squawks I will submit a patch RSN. It should be very low risk - one or two lines. Take care what you open. Perl may be a fairly secure, but the complex implementation means that problematic corner cases are regularly found. d. -- David Helgason, Business Development et al., Over the Edge I/S (http://otee.dk) Direct line +45 2620 0663 Main line +45 3264 5049 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] implemented missing bitSetBit() and bitGetBit()
On 4. feb 2004, at 20:51, Peter Eisentraut wrote: Neil Conway wrote: David Helgason [EMAIL PROTECTED] writes: I needed these, so I went and implemented them myself. I didn't see any followup to this: do we want to include this in the main tree, contrib/, or not at all? getbit sounds a lot like what substring() does. So perhaps setbit could actually be handled by replace()? That would be a more general solution (since it would handle more than one bit at a time). I sort of agree, but it's currently documented like I implemented it (afaics), so it's a simple thing to include. I feel a bit bad for not having done a full patch with test-cases and .bki modifications etc., but it seemed a pretty daunting task (for my schedule at least). Hope someone can use it though. David Helgason, Over the Edge Entertainments ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Transaction callback
On 31. jan 2004, at 18:53, Tom Lane wrote: Thomas Hallgren [EMAIL PROTECTED] writes: Ideally, I'd like a beforeCompletion that is executed prior to the start of the commit process and a afterCompletion that is called when the transaction is commited. The latter would have a status flag indicating if status is prepared (to support 2-phase commits), commited, or rolled back. And what exactly would this callback do? I imagine this would be to enforce that constraints are kept. FOREIGN KEYs can be deferred, and simple CHECK constrains can be simulated with clever foreign keys to dummy tables. Possibly allowing CHECK constraints to be deferred alleviate the need for this? The transaction commit sequence is sufficiently delicate that I'm not interested in any proposals to call random user-written code in it. The notion of a post-commit callback is even more problematic --- what is it going to do at all? It cannot modify the database, and it cannot do anything that risks getting an error, which seems to leave mighty little scope for useful activity. Surely this wouldn't effect the commit sequence. Post-commit actions could be just like cronjobs, but which are run as soon as there is a known need for them (and not otherwise). Ideally triggered triggers could install pre-commit actions during the transaction. The trigger knows: * after this particular insert/update some database logic that cannot be codified into a foreign key constraint is in an inconsistent state and must not be committed unless we are sure that some other action happened later I've had several cases of needing sth like this, but always could hack a solution using several triggers and dummy tables that I could put into an illegal state (with a deferred foreign key). Later another trigger took that table out of the illegal state if the right action was performed. David Helgason Over the Edge Entertainments ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] implemented missing bitSetBit() and bitGetBit()
I needed these, so I went and implemented them myself. I have to admit
I'm not so wise on PostgreSQL backend stuff, and so I abstained from
editing the fmgrtab.c and postgres.bki.
Sorry for that, but it just seemed too complicated. Perhaps there
should really be a script to do this? I could imagine I'm not the only
one slightly daunted by these files...
There's seems to be no reason for changing the docs since the functions
are documented as existing :)
I didn't add the other functions that one might expect to exist
(get-/set_byte and others), since I don't really need them.
I tested this code under 7.4 since that's what I've got here, but
imagine nothing much changed in this end of the world for 7.4.1...
This is to be appended to src/backend/utils/adt/varbit.c:
/*-
* bitSetBit
*
* Given an instance of type 'bit' creates a new one with
* the Nth bit set to the given value.
*
*-
*/
PG_FUNCTION_INFO_V1(bitSetBit);
Datum bitSetBit(PG_FUNCTION_ARGS)
{
VarBit *arg1 = PG_GETARG_VARBIT_P(0);
int32 n = PG_GETARG_INT32(1);
int32 newBit = PG_GETARG_INT32(2);
VarBit *result;
int bitlen,
bytelen,
byteNo,
bitNo;
unsigned char oldByte,
newByte;
bitlen = VARBITLEN(arg1);
/*
* sanity checks!
*/
if (newBit != 0 newBit != 1)
ereport(ERROR,
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg(new bit must be 0 or 1)));
if (n 0 || n = bitlen)
ereport(ERROR,
(errcode(ERRCODE_ARRAY_SUBSCRIPT_ERROR),
errmsg(bit %d outside of valid range, 0..%d,
n, bitlen - 1)));
/* Copy input bitstring */
bytelen = VARSIZE(arg1);
result = (VarBit *) palloc(bytelen);
memcpy(VARBITS(result), VARBITS(arg1), VARBITBYTES(arg1));
VARATT_SIZEP(result) = bytelen;
VARBITLEN(result) = bitlen;
/*
* Update the bit.
*/
byteNo = n / 8;
bitNo = 7 - (n % 8);
oldByte = ((unsigned char *) VARBITS(result))[byteNo];
if (newBit == 0)
newByte = oldByte (~(1 bitNo));
else
newByte = oldByte | (1 bitNo);
((unsigned char *) VARBITS(result))[byteNo] = newByte;
PG_RETURN_VARBIT_P(result);
}
/*-
* bitGetBit
*
* Given an instance of type 'bit' returns the Nth bit.
*
*-
*/
PG_FUNCTION_INFO_V1(bitGetBit);
Datum bitGetBit(PG_FUNCTION_ARGS)
{
VarBit *arg1 = PG_GETARG_VARBIT_P(0);
int32 n = PG_GETARG_INT32(1);
int bitlen,
bytelen,
byteNo,
bitNo;
unsigned char theByte;
bitlen = VARBITLEN(arg1);
/*
* sanity check!
*/
if (n 0 || n = bitlen)
ereport(ERROR,
(errcode(ERRCODE_ARRAY_SUBSCRIPT_ERROR),
errmsg(bit %d outside of valid range, 0..%d,
n, bitlen - 1)));
/*
* Find the target bit
*/
byteNo = n / BITS_PER_BYTE;
bitNo = BITS_PER_BYTE - 1 - (n % BITS_PER_BYTE);
theByte = ((unsigned char *) VARBITS(arg1))[byteNo];
/*
* Shift a set bit to target position, with the target byte, shift
back
* to get integer 0 or 1
*/
PG_RETURN_INT32((int)(theByte (1 bitNo)) bitNo);
}
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
