- 14 5月, 2000 4 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 13 5月, 2000 8 次提交
-
-
由 Tom Lane 提交于
-
由 Bruce Momjian 提交于
I'm including a diff of postgresql-7.0/src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java. I've clearly marked all the fixes I did. Would *someone* who has access to the cvs please put this in? Joseph Shraibman
-
由 Bruce Momjian 提交于
days. It seems to be a FAQ, and I think I know why. When creating a 'c' language function, CREATE FUNCTION is fed the shared object filename, and seems to succeed. Only when trying to use the function is an error thrown, by which time the coder thinks something's wrong with executing the code, not with loading it. I think I once saw it proposed to load shared objects at function creation time, but that idea was shot down on the grounds of resident memory bloat, ISTR. Here's a patch for a compromise: all it does is stat() the file, just like the loader code does, so that the errors caused by non existent files, and no directory 'x' permissions (the most common ones, it seems), get caught while the developer is still thinking about code loading. It doesn't catch all errors (like the code not being readable by the postgres user) but seems to catch the most common, without actually opening the file. What do you think? Ross
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Peter Eisentraut 提交于
-
由 Tom Lane 提交于
indexes, apparently, nor on functional indexes with more than one input column (force of natts = 1 was in the wrong branch of IF statement). Coredumped if source relation contained any uncommitted tuples, due to failure to test for success return from heap_fetch. Fetched tuple was passed directly to heap_insert, which clobbers the TID and commit status in the tuple header it's given, which meant that the source relation's tuples all got trashed as the copy proceeded. Abort partway through, and you're left with a lot of missing tuples. I wonder what else is lurking here ...
-
- 12 5月, 2000 9 次提交
-
-
由 Marc G. Fournier 提交于
this fixes the bug where setting the entry in he process table no longer works under FreeBSD ... basically, if setproctitle() exists, use it ... the draw back right now is the PS_SET_STATUS stuff doesn't work, but am looking into that one right now ... at lesat now you can see who is connecting where and from where ...
-
由 Marc G. Fournier 提交于
Add two checks ... one for setproctitle and one for -lutil ... Don't do anything with them at this time, but am working on that ...
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
Make it behave correctly when there are more than two tables being joined, also. Update regression test expected outputs.
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 11 5月, 2000 5 次提交
-
-
由 Thomas G. Lockhart 提交于
Reported by Adrian Oboroc <aoboroc@btr.md>.
-
由 Bruce Momjian 提交于
mappings. In fact, it had them backward because it was using the 6.5.* code. Copied them from parser/gram.y, so it is fixed now. Looks like our first 7.0.1 fix. Oops, seems Tom has beat me to it as I was typing this.
-
由 Tom Lane 提交于
It's still pretty fundamentally bogus :-(. Freebie side benefit: ALTER TABLE RENAME works on indexes now.
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 10 5月, 2000 4 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 09 5月, 2000 2 次提交
-
-
由 Bruce Momjian 提交于
-
由 Thomas G. Lockhart 提交于
-
- 07 5月, 2000 2 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
- 06 5月, 2000 3 次提交
-
-
由 Bruce Momjian 提交于
-
由 Bruce Momjian 提交于
-
由 Tom Lane 提交于
loading new data, for consistency with its handling of pg_shadow.
-
- 05 5月, 2000 3 次提交
-
-
由 Peter Eisentraut 提交于
-
由 Peter Eisentraut 提交于
-
由 Peter Mount 提交于
-