[2005-05-01 18:38] Andrew Dunstan said:
|
| Is there a readme somewhere on how modules are supposed to use custom
| GUC variables? If there is I have missed it.
I don't think there is any documentation for this, but here's a
simple overview.
cheers.
Brent
=== postgresql.conf ===
[2005-04-28 10:00] Tom Lane said:
| Brent Verner [EMAIL PROTECTED] writes:
|Would it be sane to recognize a specific PG_PROTOCOL_MAJOR
| to enter the filter-negotiation process? PG_PROTOCOL_MINOR
| would then be used to lookup and call a ptr to the filter's
| create
[2005-04-26 23:00] Tom Lane said:
| Brent Verner [EMAIL PROTECTED] writes:
| | I also wonder what happens when
| | the client and server disagree on the meaning of a filter name.
|
|How this is any different than saying ...when the client and
| server disagree on the meaning
[2005-04-25 18:34] Tom Lane said:
| Brent Verner [EMAIL PROTECTED] writes:
|I'd like to introduce the concept of (dynamically loaded) stream
| filters that would be used to wrap calls to send/recv by the FE/BE
| protocol.
| You certainly don't get to have any help
| from the database
[2002-05-23 10:51] Tom Lane said:
| D'Arcy J.M. Cain [EMAIL PROTECTED] writes:
| So who was it that wanted to make this change. Perhaps I can help.
|
| I forget who had volunteered to work on it, but it was several months
| ago and nothing's happened ...
I'd be the disappearing culprit...
On 25 Oct 2001 at 17:08 (-0400), David Ford wrote:
| I'm fresh in the code, but this has solved my issues with PQconnect*
| failing when interrupted by signals. Some of it is sloppy and not to my
| liking yet, but I'm still digging through to see if anything else needs
| touched. Comments
On 26 Oct 2001 at 00:05 (-0400), Tom Lane wrote:
| Brent Verner [EMAIL PROTECTED] writes:
| I'm not sure this is correct. I've tried to /make/ a SIGALRM cause
| connect to errno==EINTR, but I can't cause this condition.
|
| It wouldn't surprise me in the least if this behavior is
| platform
On 10 Oct 2001 at 17:12 (-0400), Bruce Momjian wrote:
|
| Our FAQ, item 4.16.2 has:
|
| $newSerialID = nextval('person_id_seq');
| INSERT INTO person (id, name) VALUES ($newSerialID, 'Blaise Pascal');
|
| Is this correct Perl? I don't see a nextval() function in Perl. Can
| you
On 07 Oct 2001 at 04:03 (-0700), Stephan Szabo wrote:
|
| On Sat, 6 Oct 2001, Brent Verner wrote:
|
| On 06 Oct 2001 at 20:13 (-0400), Rod Taylor wrote:
| | Of course, in 7.1 foreign key constraints become rather confused when
| | you rename columns on them.
| 1) modify this tgargs value
On 05 Oct 2001 at 10:18 (-0400), Brent Verner wrote:
| On 05 Oct 2001 at 09:46 (-0400), Tom Lane wrote:
| | Brent Verner [EMAIL PROTECTED] writes:
| | 'ALTER TABLE tbl RENAME col1 TO col2' does not update any indices that
| | reference the old column name.
| |
| | It doesn't need
The attached patch works for my case...
regression=# create table test (id serial, col1 varchar(64));
NOTICE: CREATE TABLE will create implicit sequence 'test_id_seq' for SERIAL column
'test.id'
NOTICE: CREATE TABLE/UNIQUE will create implicit index 'test_id_key' for table 'test'
CREATE
On 06 Oct 2001 at 20:13 (-0400), Rod Taylor wrote:
| Of course, in 7.1 foreign key constraints become rather confused when
| you rename columns on them.
|
| create table parent (id serial);
| create table child (id int4 references parent(id) on update cascade);
| alter table parent rename column
On 05 Oct 2001 at 09:46 (-0400), Tom Lane wrote:
| Brent Verner [EMAIL PROTECTED] writes:
| 'ALTER TABLE tbl RENAME col1 TO col2' does not update any indices that
| reference the old column name.
|
| It doesn't need to; the indexes link to column numbers, not column
| names.
Forgive my
On 17 Feb 2001 at 15:53 (-0800), Nathan Myers wrote:
| On Sat, Feb 17, 2001 at 06:30:12PM -0500, Brent Verner wrote:
| On 17 Feb 2001 at 17:56 (-0500), Tom Lane wrote:
|
| [snipped]
|
| | Is anyone out there running a 2.4 Linux kernel? Would you try pgbench
| | with current sources
On 07 Feb 2001 at 20:15 (-0500), Tom Lane wrote:
| Vince Vielhaber [EMAIL PROTECTED] writes:
| Now I get:
| byacc -d preproc.y
| byacc: f - maximum table size exceeded
| gmake[4]: *** [preproc.c] Error 2
|
| Better install bison if you want to work with CVS sources ...
| the lack of bison
On 29 Jan 2001 at 02:50 (-0500), Lamar Owen wrote:
| Lamar Owen wrote:
| ftp://ftp.postgresql.org/pub/dev/test-rpms is the place.
|
| One note: for whatever reason the date on the uploaded RPM's has the
| wrong year -- but the timestamp on my local copy has the correct date.
| In any case,
Hi,
I've the following function:
CREATE FUNCTION book_info(pricing)
RETURNS catalog_general AS '
select *
from catalog_general
where star_isbn = $1.vista_isbn
' LANGUAGE 'sql';
calling it as:
SELECT p.*, p.book_info.title FROM pricing p WHERE vista_ans='POD';
background
On 24 Jan 2001 at 12:14 (-0500), Tom Lane wrote:
| Brent Verner [EMAIL PROTECTED] writes:
| calling it as:
|SELECT p.*, p.book_info.title FROM pricing p WHERE vista_ans='POD';
| background and observation:
|the pricing table is fairly large, but only a small number meet
|"
Hi,
It turns out the problem causing the oid failures is with our
snprintf. specifically we are formatting "%u" incorrectly:
using a enhanced-for-testing version of our snprintf I get.
formatting '-1040' with '%lu'
snprintf = 18446744073709550576
sprintf = 18446744073709550576
On 30 Dec 2000 at 14:24 (-0500), Tom Lane wrote:
| Brent Verner [EMAIL PROTECTED] writes:
| formatting '-1040' with '%u'
| snprintf = 18446744073709550576
| sprintf = 4294966256
|
| oidout() is where the offending call originates, FWIW.
| snprintf(result, 12, "%u", o)
On 27 Dec 2000 at 21:37 (-0500), Tom Lane wrote:
| Brent Verner [EMAIL PROTECTED] writes:
|This is a revised patch that I sent earlier to allow building
| pg-7.1 with gcc as well as DEC's cc. I've had good results with this
| applied. Could some other Alpha users try this out. Even better
On 28 Dec 2000 at 17:03 (+0200), Adriaan Joubert wrote:
| Hi,
|
| I missed the beginning of this thread. Are you doing this for Tru64 or
| for Linux? For Tru64 there are macros in /usr/include/alpha/builtins.h
| which do the job.
gcc + Tru64, since gcc-2.95.2 doesn't implement the
On 28 Dec 2000 at 10:48 (-0500), Tom Lane wrote:
| Brent Verner [EMAIL PROTECTED] writes:
| another loop-free version of TAS that /seems/ to work as desired.
|
| Since it doesn't check to see if the stq_c succeeded, it can't possibly
| be right...
right, I just realized that while composing
On 28 Dec 2000 at 12:41 (-0500), Tom Lane wrote:
| Brent Verner [EMAIL PROTECTED] writes:
| I see this with the version of TAS() that you recently suggested, but not
| with either of the versions I'd hacked up.
|
| Hm. Your second version might incorrectly appear to work because it's
On 28 Dec 2000 at 17:40 (-0500), Tom Lane wrote:
| Okay ... I guess the LOCK_LONG macros are our best shot. Here is a
| proposed new Alpha section for s_lock.h. Would you try it and let me
| know how it works for you?
|
| Note that this will NOT fix the CreateCheckPoint shutdown error; don't
|
On 26 Dec 2000 at 23:41 (-0500), Tom Lane wrote:
| Brent Verner [EMAIL PROTECTED] writes:
| | Please apply it locally and let me know what you find.
|
| what I'm seeing now is much the same.
|
| Drat. More to do, then.
after hours in the gdb-hole, I see this... maybe a clue? :)
src/include
On 27 Dec 2000 at 21:45 (-0500), Tom Lane wrote:
| Brent Verner [EMAIL PROTECTED] writes:
| | Hm. I thought I'd fixed that. Are you up to date on
| | src/backend/utils/adt/oid.c ? Current CVS has rev 1.42.
|
| yup. got that version -- 1.42 2000/12/22 21:36:09 tgl
|
| You're right
On 26 Dec 2000 at 14:41 (-0500), Tom Lane wrote:
| I wrote:
| ... What I'm thinking about doing is setting typmod of
| an entire-tuple function argument to sizeof(Pointer), rather than
| the default -1, to indicate that a pointer representation is being
| used. Comments, hackers?
|
| Here
On 26 Dec 2000 at 23:41 (-0500), Tom Lane wrote:
| Brent Verner [EMAIL PROTECTED] writes:
| | Please apply it locally and let me know what you find.
|
| what I'm seeing now is much the same.
sorry, I sent the previous email w/o the details of the different
behavior. Inside
On 24 Dec 2000 at 01:19 (-0500), Tom Lane wrote:
| Brent Verner [EMAIL PROTECTED] writes:
| (gdb) p *resSlot
| Error accessing memory address 0x40141830: Invalid argument.
|
| Oooh. resSlot has been truncated to 32 bits --- judging by the other
| nearby pointer values, it almost certainly
here's a post-mortem.
#0 0x1200ce58c in ExecEvalFieldSelect (fselect=0x1401615c0,
econtext=0x14016a030, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1096
#1 0x1200ceafc in ExecEvalExpr (expression=0x1401615f0, econtext=0x0,
isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1234
On 24 Dec 2000 at 01:00 (-0500), Tom Lane wrote:
| Brent Verner [EMAIL PROTECTED] writes:
| here's a post-mortem.
|
| #0 0x1200ce58c in ExecEvalFieldSelect (fselect=0x1401615c0,
| econtext=0x14016a030, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1096
|
| Looks reasona
the same, esp the
FAILURE of misc regression test.
If there is anything else I can do to help get this working, please
let me know.
Brent Verner
On 22 Dec 2000 at 20:27 (-0500), Brent Verner wrote:
observation:
commenting out the queries with 'FROM person* p' causes the misc
regression test to pass.
SELECT p.name, p.hobbies.name FROM person* p;
Brent
| Hi,
| I saw the thread from a few days ago about Linux/Alpha and 7.1
On 22 Dec 2000 at 21:58 (-0500), Brent Verner wrote:
| On 22 Dec 2000 at 20:27 (-0500), Brent Verner wrote:
|
| observation:
|
| commenting out the queries with 'FROM person* p' causes the misc
| regression test to pass.
that's not what I meant to say. the misc test still FAILS
35 matches
Mail list logo
