Re: [PATCHES] array support patch phase 1 patch

2003-06-24 Thread Joe Conway
Bruce Momjian wrote: Patch applied. Joe, I need some text about this patch for the release notes. It has so much stuff in it I don't know how to describe it. OK -- I'll send you something. I need to finish the documentation also, so I'll send both at once. Joe

Re: [PATCHES] [NOVICE] connectby() minor bug in errormessage

2003-06-24 Thread Joe Conway
Nabil Sayegh wrote: validateConnectbyTupleDesc When the fourth column (tupdesc-attrs[3]) fails the type check, the errormessage should be fourth column must be... and not third column must be ... line 1372 http://www.joeconway.com/tablefunc.tar.gz Attached is a patch for the issue reported above

Re: [PATCHES] [GENERAL] bytea char escaping

2003-06-25 Thread Joe Conway
Stephen Robert Norris wrote: Well, no. What it says is that certain values must be escaped (but doesn't say which ones). Then it says there are alternate escape sequences for some values, which it lists. It doesn't say The following table contains the characters which must be escaped:, which would

Re: [PATCHES] [HACKERS] allowed user/db variables

2003-06-25 Thread Joe Conway
(moved to PATCHES) Tom Lane wrote: I agree with this plan also. I'm not sure if the RH guys had intended to get around to this or not --- it's not on their shortlist of stuff they need for their tools. The proposed patch from RH includes addition of descriptions to the variables' table entries

Re: [PATCHES] array support patch phase 1 patch

2003-06-27 Thread Joe Conway
Peter Eisentraut wrote: Bruce Momjian writes: Patch applied. Joe, I need some text about this patch for the release notes. It has so much stuff in it I don't know how to describe it. This patch still contained documentation of functions array_subscript(), array_assign() which were not included

Re: [PATCHES] [HACKERS] Missing array support

2003-06-29 Thread Joe Conway
Joe Conway wrote: Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: Included in the patch, I changed SQL language functions so that they could be declared with and use polymorphic types. I'm not convinced that will work ... in particular, does the parsetree get fixed correctly when a SQL

[PATCHES] polymorphic arguments and return type for PL/pgSQL

2003-06-30 Thread Joe Conway
The attached patch enables PL/pgSQL functions (but not triggers) to accept and return polymorphic types. It is careful to return false from func_up_to_date() if any of the polymorphic types change from call-to-call. It also falls back to the pg_proc declared types if the caller didn't setup

Re: [PATCHES] [HACKERS] Missing array support

2003-06-30 Thread Joe Conway
Tom Lane wrote: Thinking about this further, it occurs to me that there's no hard reason plpgsql (and other PLs that adopt the we-can-convert-anything-to-string philosophy, such as pltcl) couldn't allow arguments (though not results) of type ANY. It's not different from accepting ANYELEMENT as

Re: [PATCHES] fix for plpgsql polymorphism

2003-07-02 Thread Joe Conway
Alvaro Herrera wrote: why is this a malloc() and not palloc()? And when/where/how is it freed? It isn't, at least not until the backend exits ;-) This is how plpgsql is done throughout, pretty much. It's not so bad when you remember that plpgsql functions are compiled once, and then cached

Re: [PATCHES] fix for plpgsql polymorphism

2003-07-02 Thread Joe Conway
Tom Lane wrote: Ugh. That seems like a really crude way to handle things. In the first place, a variable adds overhead whether you need it or not; in the second place, what's the value of the variable if I try to fetch it, or the effects if I assign to it? $0 seems like a rather randomly-chosen

Re: [PATCHES] fix for plpgsql polymorphism

2003-07-03 Thread Joe Conway
Tom Lane wrote: You can alias $0, similar to the argument variables. And, I confirmed that you cannot change the value, similar to the argument variables: Perhaps you shouldn't mark it isconst; then it would actually have some usefulness (you could use it directly as a temporary variable to hold

Re: [PATCHES] Proof-of-concept for initdb-time shared_buffers selection

2003-07-04 Thread Joe Conway
Tom Lane wrote: 1. Does this approach seem like a reasonable solution to our problem of some machines having unrealistically small kernel limits on shared memory? Yes, it does to me. 2. If so, can I get away with applying this post-feature-freeze? I can argue that it's a bug fix, but perhaps

Re: [PATCHES] [NOVICE] connectby(... pos_of_sibling)

2003-07-17 Thread Joe Conway
Bruce Momjian wrote: Joe, would you comment on this change to tablefunc connectby? I actually tied up a few loose ends on this and submitted it to PATCHES on 6/26/2003. See: http://archives.postgresql.org/pgsql-patches/2003-06/msg00357.php Joe ---(end of

Re: [PATCHES] fix for plpgsql polymorphism

2003-07-18 Thread Joe Conway
I'm going to resend the patches that I have outstanding since it appears some may have been lost. Here's the first. == Tom Lane wrote: You can alias $0, similar to the argument variables. And, I confirmed that you cannot change the value, similar to the

Re: [PATCHES] [NOVICE] connectby(... pos_of_sibling)

2003-07-18 Thread Joe Conway
I'm going to resend the patches that I have outstanding since it appears some may have been lost. Here's the second of three. Nabil Sayegh wrote: Am Son, 2003-06-22 um 02.09 schrieb Joe Conway: Sounds like all that's needed for your case

Re: [PATCHES] [HACKERS] allowed user/db variables

2003-07-18 Thread Joe Conway
I'm going to resend the patches that I have outstanding since it appears some may have been lost. Here's the third of three. === Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: ISTM that source is worth knowing. Hm, possibly. Any other

[PATCHES] patch for compile warning on date.c

2003-07-23 Thread Joe Conway
I just noticed a new compile warning on date.c. Attached patch fixes it. Joe Index: src/backend/utils/adt/date.c === RCS file: /opt/src/cvs/pgsql-server/src/backend/utils/adt/date.c,v retrieving revision 1.85 diff -c -r1.85 date.c

[PATCHES] array expression NULL fix [was: [HACKERS] odd behavior/possible bug]

2003-07-24 Thread Joe Conway
Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: That probably makes good sense, at least until we can deal with NULL elements. Would that patch count as a bug fix? Either one would count as a bug fix IMHO. Anyone else have an opinion on which to do? Here's a patch that replaces the ERROR

[PATCHES] preload libraries patch [was: [GENERAL] hexadecimal to decimal]

2003-07-31 Thread Joe Conway
Tom Lane wrote: It seems entirely sensible to me for the postmaster to choke on invalid settings in postgresql.conf. Better than failing to mention the problem at all, anyway. 2) do you want a patch that exports plperl_init_all() (and I guess similar init functions in pltcl and plpython)? Yeah,

Re: [PATCHES] preload libraries patch [was: [GENERAL] hexadecimal to decimal]

2003-07-31 Thread Joe Conway
Tom Lane wrote: As coded, this will cause pltcl to try to execute the unknown-module load on every pltcl function call :-(. You really need two bits of state if you are going to have separate postmaster-time and backend-time initialization. Hmmm, I see your point :(. Sorry about that! Will fix

[PATCHES] contrib regression test update

2003-07-31 Thread Joe Conway
Quoting behavior changed in the message that produces, e.g.: NOTICE: type seg is not yet defined This patch updates all the contrib regression tests for the change. Please apply. Thanks, Joe Index: contrib/btree_gist/expected/btree_gist.out

Re: [PATCHES] [HACKERS] statement level trigger causes pltcl, plpython SIGSEGV

2003-08-03 Thread Joe Conway
Joe Conway wrote: I'll try to submit a patch later tonight or tomorrow morning if no one beats me to it. Here's a patch for pltcl. It works for my test case: CREATE OR REPLACE FUNCTION footrigfunc() RETURNS trigger AS 'return OK' LANGUAGE pltcl; CREATE TRIGGER footrig BEFORE INSERT OR UPDATE

[PATCHES] more bad markup -- jdbc.sgml

2003-08-06 Thread Joe Conway
Second case of bad markup today. Someone from the jdbc camp might want to look at this, but I took a shot at fixing it so I could keep working on my own doc updates. Joe p.s. Just a friendly reminder ;-) cd doc/src/sgml make check Title: Getting results based on a cursor Index:

[PATCHES] array/polymorphic function doc cleanup

2003-08-07 Thread Joe Conway
I think this rounds off the documentation updates that I owed for array and polymorphic function/aggregate changes. Let me know if you think I missed anything major. In any case, please apply. Thanks, Joe Index: doc/src/sgml/array.sgml

Re: [PATCHES] [HACKERS] IS OF

2003-08-09 Thread Joe Conway
Tom Lane wrote: In fact you could argue that our current behavior is *more* useful than what the spec says for polymorphics. You would not want the special case for NULLs, in most cases, I'd think. NULLs have perfectly well defined datatype. That's actually exactly what I was thinking. However,

Re: [PATCHES] [HACKERS] IS OF

2003-08-12 Thread Joe Conway
Joe Conway wrote: Peter Eisentraut wrote: I suggest I should not be documented until it's fixed. Doc patch attached for IS OF. Please apply. That is not the right place for it. IS OF is an operator, not an SQL command. OK. If the attached patch is acceptable/applied, I'll fix and resend the doc

Re: [PATCHES] [HACKERS] IS OF

2003-08-14 Thread Joe Conway
Peter Eisentraut wrote: I suggest I should not be documented until it's fixed. Doc patch attached for IS OF. Please apply. That is not the right place for it. IS OF is an operator, not an SQL command. OK. If the attached patch is acceptable/applied, I'll fix and resend the doc patch. Joe

Re: [PATCHES] [HACKERS] IS OF

2003-08-14 Thread Joe Conway
Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: OK. If the attached patch is acceptable/applied, I'll fix and resend the doc patch. I'm unconvinced that the parse-time-constant implementation Lockhart started has anything whatever to do with the semantics the SQL99 spec has in mind. Yeah

[PATCHES] array concat, et al patch (was: [GENERAL] join of array)

2003-08-15 Thread Joe Conway
Tom Lane wrote: Could you look at how big a change it'd be, anyway? Offhand I think it may just mean that the subscript-checking done in parse_expr.c needs to be done at runtime instead. Remember parse_expr should only be concerned about determining datatype, and for its purposes all arrays of a

Re: [PATCHES] array concat, et al patch

2003-08-17 Thread Joe Conway
Tom Lane wrote: Applied with only marginal changes. (I thought the element-type checks removed from parse_expr.c had better be applied at runtime; and I noticed that array_cat scribbled on its inputs in some cases.) Thanks! You're on the hook for docs fixes... I'm on it. Joe

Re: [PATCHES] array concat, et al patch

2003-08-18 Thread Joe Conway
Tom Lane wrote: You're on the hook for docs fixes... Here's a patch for the documentation updates. Please apply. Thanks, Joe Index: doc/src/sgml/array.sgml === RCS file: /opt/src/cvs/pgsql-server/doc/src/sgml/array.sgml,v retrieving

Re: [PATCHES] [HACKERS] New array functions

2003-08-31 Thread Joe Conway
Joe Conway wrote: Tom Lane wrote: Did we discuss this already? I'd forgotten. I can't find it in the archives for some reason, but here was the exchange: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Joe Conway wrote: I do agree that it makes contrib/array unnecessary. I

[PATCHES] bug fix: TupleDescGetAttInMetadata/BuildTupleFromCStrings with dropped cols

2003-09-21 Thread Joe Conway
I discovered that TupleDescGetAttInMetadata and BuildTupleFromCStrings don't deal well with tuples having dropped columns. The attached fixes the issue. Please apply. Thanks, Joe Index: src/backend/executor/execTuples.c === RCS

Re: [PATCHES] tablefunc functions in postgresql

2003-10-01 Thread Joe Conway
Attached is a patch for contrib/tablefunc. It fixes two issues raised by Lars Boegild Thomsen (full email below) and also corrects the regression expected output for a recent backend message adjustment. Please apply. Thanks, Joe Lars Boegild Thomsen wrote: Dear Mr. Conway, I've noticed that

Re: [PATCHES] Problem with dblink

2003-11-21 Thread Joe Conway
Andrea Grassi wrote: [...using dblink_build_sql_insert() inside a PL/pgSQL function...] ERROR: improper call to spi_printtup CONTEXT: PL/pgSQL function f_sync_trigger_a_clifor line 6 at select into variables Attached fixes a recently reported bug in dblink. If there are no objections, I'll

Re: [PATCHES] Problem with dblink

2003-11-21 Thread Joe Conway
Tom Lane wrote: Looks right to me; but as a general tip, if you've made mistake X in place A, you might have made it in place B too. Have you checked the rest of dblink for forgotten SPI_finish calls? Good tip -- will do. Though, I suspect the dblink_build_sql_* functions have been much more

[PATCHES] make installcheck on non-default ports

2003-11-25 Thread Joe Conway
I was trying to set up my dev box for multiple simultaneous Postgres installs (7.3 stable, 7.4 stable, cvs head) and discovered that `make installcheck` did not honor the default port assigned at configure time. I view this as a bug. The attached resolves the issue for all three versions. Any

Re: [PATCHES] make installcheck on non-default ports

2003-11-25 Thread Joe Conway
Joe Conway wrote: I was trying to set up my dev box for multiple simultaneous Postgres installs (7.3 stable, 7.4 stable, cvs head) and discovered that `make installcheck` did not honor the default port assigned at configure time. I view this as a bug. The attached resolves the issue for all

Re: [PATCHES] make installcheck on non-default ports

2003-11-25 Thread Joe Conway
Tom Lane wrote: I think there is something wrong with your setup procedures, because I've never needed such. (I've corresponded with Joe off-list about this --- maybe we can produce a FAQ about the right way to do it once the dust settles.) Yup, got it. AFAICS this would defeat the documented

Re: [PATCHES] Problem with dblink

2003-11-26 Thread Joe Conway
Tom Lane wrote: Looks right to me; but as a general tip, if you've made mistake X in place A, you might have made it in place B too. Have you checked the rest of dblink for forgotten SPI_finish calls? That function was the only one using SPI calls in dblink, so there were no others. Fix applied

Re: [PATCHES] Problem with dblink

2003-11-26 Thread Joe Conway
Tom Lane wrote: Yeah, I think to apply it to a stable branch you'd want some indication that there are more live bugs out there that it's needed to catch. At the moment it only seems called for as an aid to future development, and so HEAD seems sufficient. Thanks, that's what i thought. On a

Re: [PATCHES] Problem with dblink

2003-11-26 Thread Joe Conway
Christopher Kings-Lynne wrote: I saw them, User Joe :) Yeah, they just showed up for me too. I'll have to figure out how to change that from User Joe to something else -- sounds kind of strange ;-) Joe ---(end of broadcast)--- TIP 8: explain

Re: [PATCHES] Problem with dblink

2003-11-26 Thread Joe Conway
Bruce Momjian wrote: Joe Conway wrote: Yeah, they just showed up for me too. I'll have to figure out how to change that from User Joe to something else -- sounds kind of strange ;-) Marc just fixed it. Ah, great! Thanks Marc :-) Joe ---(end of broadcast

Re: [PATCHES] contrib/dbmirror conditional replication

2003-11-29 Thread Joe Conway
Steven Singer wrote: Downsides include that the code is kind of complicated, insert,updates and deletes are much slower and a lot of extra information needs to be stored by the mirroring system(see the accounting table). I second this part. I added a compile time flag to enable or disable this

[PATCHES] PG_VERSION in pg_config.h.win32

2003-11-29 Thread Joe Conway
PG_VERSION should be 7.5devel (not 7.4) in pg_config.h.win32, shouldn't it? Joe Index: src/include/pg_config.h.win32 === RCS file: /cvsroot/pgsql-server/src/include/pg_config.h.win32,v retrieving revision 1.12 diff -c -r1.12

[PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable (was: [GENERAL] SELECT Question)

2003-11-29 Thread Joe Conway
Tom Lane wrote: I was thinking of proposing that we provide something just about like that as a standard function (written in C, not in plpgsql, so that it would be available whether or not you'd installed plpgsql). There are some places in the information_schema that desperately need it ---

Re: [PATCHES] [BUGS] Bug in byteaout code in all PostgreSQL versions

2003-11-30 Thread Joe Conway
Bruce Momjian wrote: Joe Conway has an updated version of this he will be applying shortly. Thanks. Joe, please make sure you CC this person once your patch is applied. I just applied the attached patch to cvs head, and equivalent ones on the 7.3 and 7.4 stable branches. I also attached

Re: [PATCHES] Problem with dblink

2003-11-30 Thread Joe Conway
Tom Lane wrote: 1. AFAIR, all the other at-end-of-xact routines that take a flag telling them if it's commit or abort define the flag as isCommit. Having the reverse convention for this one routine is confusing and a recipe for errors, so please make it be isCommit too. Done. 2. The initial

Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable

2003-11-30 Thread Joe Conway
Tom Lane wrote: One could make a good case that INDEX_MAX_KEYS should be exported along with FUNC_MAX_ARGS, rather than letting people write client code that assumes they are the same. I was intending to propose that we also export the following as read-only variables: * NAMEDATALEN

Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable

2003-11-30 Thread Joe Conway
Tom Lane wrote: Perhaps the GUC variable name should be max_name_len or some such. Also, should func_max_args and index_max_keys become max_func_args and max_index_keys? That sounds good to me: -[ RECORD 3 ]-- name | max_func_args setting| 32

Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable

2003-12-01 Thread Joe Conway
Bruce Momjian wrote: Joe Conway wrote: name | block_size OK. Should that be page_size? Not sure but block size sounds more like a hardware setting. I know we call it BLCKSZ in our code but page size seems more appropriate. Not sure. Seems like block_size is more appropriate to me. Any

Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable

2003-12-01 Thread Joe Conway
Bruce Momjian wrote: Joe Conway wrote: The description is a statement because the option is boolean, i.e. the statement Datetimes are integer based is either true or false (on or off, etc). How stongly do you feel about it? I don't think integer_datetime_storage is accurate in any case

Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable

2003-12-01 Thread Joe Conway
Bruce Momjian wrote: Any more thoughts on block_size (or page_size)? When I think of block size I think of disk blocks, and when I think of pages I think of memory pages. Unfortunately, neither is a database page. I guess my point is that we have heap pages and index pages, but no one calls them

Re: [PATCHES] export FUNC_MAX_ARGS as a read-only GUC variable

2003-12-01 Thread Joe Conway
Bruce Momjian wrote: Peter Eisentraut wrote: Joe Conway writes: Any more thoughts on block_size (or page_size)? It's always been some variant spelling of block size, and I see no reason to change the terminology. Yes, that is from a coder's perspective, but from the user/admin perspective

Re: [PATCHES] [HACKERS] bytea, index and like operator again and detailed report

2003-12-06 Thread Joe Conway
Alvar Freude wrote: -- Joe Conway [EMAIL PROTECTED] wrote: Please try the attached patch and let me know how it works for you. It is against cvs HEAD, but should apply OK to 7.4. so, I checked it with my database. It looks good, all checks I made are OK. The attached fixes the bytea-like bug

Re: [PATCHES] [GENERAL] SELECT Question

2004-01-28 Thread Joe Conway
Tom Lane wrote: I was thinking of proposing that we provide something just about like that as a standard function (written in C, not in plpgsql, so that it would be available whether or not you'd installed plpgsql). There are some places in the information_schema that desperately need it ---

Re: [HACKERS] [PATCHES] v7.4.1 text_position() patch

2004-01-31 Thread Joe Conway
Tatsuo Ishii wrote: Thanks. Please apply it. Applied to REL7_3_STABLE. Thanks, Joe ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html

[PATCHES] pg_generate_sequence and info_schema patch (Was: SELECT Question)

2004-01-31 Thread Joe Conway
Joe Conway wrote: Tom Lane wrote: I was thinking of proposing that we provide something just about like that as a standard function (written in C, not in plpgsql, so that it would be available whether or not you'd installed plpgsql). There are some places in the information_schema

Re: [PATCHES] pg_generate_sequence and info_schema patch (Was: SELECT

2004-02-01 Thread Joe Conway
Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: regression=# select * from pg_generate_sequence(8, 4); ERROR: finish is less than start Hm, would it be better just to return an empty set? Certainly I'd expect pg_generate_sequence(1,0) to return an empty set with no error. OK

Re: [PATCHES] pg_generate_sequence and info_schema patch (Was: SELECT

2004-02-01 Thread Joe Conway
Tom Lane wrote: folklore has it that Mariner II was lost to exactly such a bug). Ouch -- got the point. If you want to allow the 3-parameter form to specify a negative step size, that's fine. But don't use a heuristic to guess the intended step direction. The attached patch implements the

Re: [PATCHES] pg_generate_sequence and info_schema patch (Was: SELECT

2004-02-03 Thread Joe Conway
Tom Lane wrote: BTW, I think I was beating you over the head with an urban legend. Some idle googling revealed the true facts of the Mariner failure: http://www.rchrd.com/Misc-Texts/Famous_Fortran_Errors Oh well, I've been beat over the head with worse things, at least metaphorically ;-).

Re: [PATCHES] pg_generate_sequence and info_schema patch (Was: SELECT

2004-02-04 Thread Joe Conway
Christopher Kings-Lynne wrote: Having something that generates a list of dates would be handy, however I guess you can do it with the current series generator by adding that many day intervals to a base date... Seems to work: regression=# select current_date + s.a as dates from

Re: [PATCHES] pg_generate_sequence and info_schema patch (Was: SELECT

2004-02-04 Thread Joe Conway
Gaetano Mendola wrote: select * from generate_series(5,1,-2); I understood on your past posts that instead this result was obtained with: select * from generate_series(5,1,2); ~ generate_series - - ~ 5 ~ 3 ~ 1 (3 rows) Tom objected to the

Re: [PATCHES] dblink - custom datatypes NOW work :)

2004-02-22 Thread Joe Conway
Mark Gibson wrote: Joe Conway wrote: Please give this a try and let me know what you think. Fantastic, works perfectly (well I've only actually tested it with the 'txtidx' datatype). That's so much better than my idea, i didn't like having the oid map much anyway. Oh well, I least I've learnt I

Re: [PATCHES] [GENERAL] connectby for BYTEA keys

2004-02-22 Thread Joe Conway
David Garamond wrote: Joe Conway wrote: --with attached patch regression=# SELECT * FROM connectby('connectby_bytea', 'keyid', 'parent_keyid', 'row\\134', 0, '') AS t(keyid bytea, parent_keyid bytea, level int, branch text); Thanks for the fix. I plan to apply this to 7.3 7.4 stable as well

Re: [PATCHES] [GENERAL] dblink: rollback transaction

2004-02-22 Thread Joe Conway
Oleg Lebedev wrote: Your fix is awesome! That's exactly what I need. What version of postgres do I need to have installed to try this patch? I am on 7.3 now. I plan to apply the attached to cvs tip in 24 hours or so. I don't think it qualifies as a bug fix, and it does represent a change in user

Re: [PATCHES] dblink - custom datatypes NOW work :)

2004-02-23 Thread Joe Conway
Tom Lane wrote: Two nitpicks (each applying in 2 places): First, testing for null rsinfo isn't sufficient, since the resultinfo mechanism could be used for other things; you need an IsA test too. Second, is syntax error really the most appropriate classification for this? (Also, the errmsg text

Re: [PATCHES] [GENERAL] dblink: rollback transaction

2004-02-23 Thread Joe Conway
Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: One question that I'd like some feedback on is the following: should the same change be applied to other functions that might throw an ERROR based on the remote side of the connection? For example, currently if dblink() is used in an attempt

Re: [PATCHES] [GENERAL] dblink: rollback transaction

2004-02-23 Thread Joe Conway
Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: I like the idea in general, but maybe instead there should be a new overloaded version of the existing function names that accepts an additional bool argument. Without the argument, behavior would be as it is now; with it, you could specify

Re: [PATCHES] [GENERAL] dblink: rollback transaction

2004-03-04 Thread Joe Conway
Joe Conway wrote: Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: I like the idea in general, but maybe instead there should be a new overloaded version of the existing function names that accepts an additional bool argument. Without the argument, behavior would be as it is now

[PATCHES] contrib/fuzzystrmatch updates

2004-06-30 Thread Joe Conway
If there are no objections, I intend to commit the attached tonight or tomorrow. Changes as follows: - Adds double metaphone code from Andrew Dunstan - Change metaphone so that an empty input string causes an empty output string to be returned, instead of throwing an ERROR.

Re: [PATCHES] latest plperl

2004-06-30 Thread Joe Conway
Andrew Dunstan wrote: The attached patch (and 2 new files incorporating previous eloglvl.[ch] as before) has the following changes over previously sent patch (fixes all by me): - fix null - undef mappings - fix GNUmakefile to honor rpath configuration, and remove ugly compile arnings due to

Re: [PATCHES] latest plperl

2004-06-30 Thread Joe Conway
Tom Lane wrote: Are there any other pending patches you're interested in taking responsibility for? Yeah, I know you've been especially overloaded lately, and I feel badly that I've not been able to help out in recent months :-( If you have some specific patches in mind, I can try to work on one

Re: [PATCHES] contrib/dbmirror

2004-06-30 Thread Joe Conway
[EMAIL PROTECTED] wrote: Attached is a 1 line bug fix for dbmirror that was submitted. It fixes a bug where some transactions could be dropped when writing mirrored SQL statements to files. I know that there were discussions regarding removing the replication contribs (rserv and dbmirror) prior

Re: [PATCHES] latest plperl

2004-06-30 Thread Joe Conway
Andrew Dunstan wrote: The attached patch (and 2 new files incorporating previous eloglvl.[ch] as before) has the following changes over previously sent patch (fixes all by me): The patch file itself seems to be empty -- please resend. Thanks, Joe ---(end of

Re: [PATCHES] latest plperl

2004-07-01 Thread Joe Conway
Andrew Dunstan wrote: The attached patch (and 2 new files incorporating previous eloglvl.[ch] as before) has the following changes over previously sent patch (fixes all by me): Some comments below: In plperl_trigger_build_args(), this looks bogus: + char *tmp; + +

Re: [PATCHES] latest plperl

2004-07-01 Thread Joe Conway
Andrew Dunstan wrote: I will do some checking on these changes, but with those caveats they look good to me. Attached is an all inclusive revised patch. Please review and comment. If there are no objections, I'll commit in a few hours. As a side note, I think it would be *really* helpful if

Re: [PATCHES] latest plperl

2004-07-01 Thread Joe Conway
Andrew Dunstan wrote: Doh! Very bogus! sizeof(int)and a malloc to boot ??? I didn't check the trigger code much because it has supposedly been working for quite a while. I will examine more closely. Well, essentially 4 bytes (sizeof(int)) were being allocated to print a two byte interger that can

Re: [PATCHES] pg_tablespace_databases

2004-07-01 Thread Joe Conway
Andreas Pflug wrote: From an idea of Bruce, the attached patch implements the function pg_tablespace_databases(oid) RETURNS SETOF oid which delivers as set of database oids having objects in the selected tablespace, enabling an admin to examine only the databases affecting the tablespace for

Re: [PATCHES] latest plperl

2004-07-01 Thread Joe Conway
Andrew Dunstan wrote: Joe Conway said: As a side note, I think it would be *really* helpful if there were a more comprehensive test script, and an expected results file available. Not sure though if it could be included in the standard regression tests on a configure-conditional basis -- anyone

Re: [PATCHES] contrib/dbmirror

2004-07-01 Thread Joe Conway
[EMAIL PROTECTED] wrote: Attached is a 1 line bug fix for dbmirror that was submitted. It fixes a bug where some transactions could be dropped when writing mirrored SQL statements to files. Patch applied. Joe ---(end of broadcast)--- TIP 1:

Re: [PATCHES] pg_tablespace_databases

2004-07-01 Thread Joe Conway
Andreas Pflug wrote: From an idea of Bruce, the attached patch implements the function pg_tablespace_databases(oid) RETURNS SETOF oid which delivers as set of database oids having objects in the selected tablespace, enabling an admin to examine only the databases affecting the tablespace for

Re: [PATCHES] pg_tablespace_databases

2004-07-02 Thread Joe Conway
Tom Lane wrote: [ shrug... ] The name is not going to change again. I have never cared for the practice of writing strlen(foo) as if it were a compile-time constant. But certainly it would be entirely pointless to define such a macro and then use it in only one place. Fair enough. If there are

Re: [PATCHES] pg_tablespace_databases

2004-07-02 Thread Joe Conway
Joe Conway wrote: Tom Lane wrote: [ shrug... ] The name is not going to change again. I have never cared for the practice of writing strlen(foo) as if it were a compile-time constant. But certainly it would be entirely pointless to define such a macro and then use it in only one place. Fair

Re: [PATCHES] Another transation fix

2004-07-31 Thread Joe Conway
Bruce Momjian wrote: Here is another try at fixing the translation message. Instead of removing the backslashes in the message, I escaped them. Per discussion with Joe Conway. Now I'm getting three errors instead of one: msgfmt -o po/zh_TW.mo po/zh_TW.po po/zh_TW.po:199: `msgid' and `msgstr

Re: [PATCHES] Another transation fix

2004-07-31 Thread Joe Conway
Joe Conway wrote: Bruce Momjian wrote: Here is another try at fixing the translation message. Instead of removing the backslashes in the message, I escaped them. Per discussion with Joe Conway. Now I'm getting three errors instead of one: msgfmt -o po/zh_TW.mo po/zh_TW.po po/zh_TW.po:199

Re: [PATCHES] [BUGS] casting strings to multidimensional arrays yields strange

2004-08-04 Thread Joe Conway
Tom Lane wrote: [ cc'ing pghackers in case anyone wants to object ] Joe Conway [EMAIL PROTECTED] writes: I think that even once we support NULL array elements, they should be explicitly requested -- i.e. throwing an error on non-rectangular input is still the right thing to do. I haven't

Re: [PATCHES] [HACKERS] compile warnings

2004-08-04 Thread Joe Conway
Joe Conway wrote: Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: In addition to the ecpg warnings mentioned by Tom, I'm also seeing compile warnings wrt plpython: This is surely not a must fix tomorrow issue, but please look into it when you get back from your road trip. I find that simply

Re: [PATCHES] [BUGS] casting strings to multidimensional arrays yields strange

2004-08-05 Thread Joe Conway
Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: While looking at it the last day or so, I started to think it might be better to use bison to parse array literals -- or is that a bad idea? Offhand it doesn't seem like a super-appropriate tool. Once you get past the lexical details like

Re: [PATCHES] Patch for Array min() / max()

2004-08-07 Thread Joe Conway
Bruce Momjian wrote: May I have a context diff please, diff -c? As this is new functionality, I presume it will be held for 8.1, correct? In any case, you can put my name on it for review. Joe ---(end of broadcast)--- TIP 1: subscribe and

Re: [PATCHES] [SQL] array_in: '{}}'::text[]

2004-08-27 Thread Joe Conway
Joe Conway wrote: Markus Bertheau wrote: Is there a reason the array_in parser accepts additional closing braces at the end? oocms=# SELECT '{}}'::text[]; text -- {} (1 ) Hmmm, I was *about* to say that this is fixed in cvs (and indeed, the array_in parser is significantly tightened up

Re: [PATCHES] [SQL] array_in: '{}}'::text[]

2004-08-28 Thread Joe Conway
Tom Lane wrote: actually, why isn't this just a pstrdup? Why not just if (strcmp(str, {}) == 0) Good points. Changes made, and attached committed. Joe Index: src/backend/utils/adt/arrayfuncs.c === RCS file:

Re: [PATCHES] [SQL] array_in: '{}}'::text[]

2004-08-28 Thread Joe Conway
Markus Bertheau wrote: Without looking at the code in a whole, you accept '{} ' as an empty array literal, so why is the special case for '{}' needed here? It's a fast path for a common special case. Why spend any cycles parsing if we can immediately recognize it? However, anything other than a

Re: [PATCHES] [HACKERS] x86_64 configure problem

2004-09-16 Thread Joe Conway
Peter Eisentraut wrote: Joe Conway wrote: One procedural issue did occur to me regarding this kind of change. It requires someone to run autoconf after applying -- how is that normally handled? You run autoconf before you commit and then check it in. Please use version 2.53. Thanks. Attached

Re: [PATCHES] plpython win32

2004-09-25 Thread Joe Conway
Magnus Hagander wrote: The distutils module has a get_python_inc() function which returns the include directory. If this one was used, we wouldn't have to hack up the include path as I do now. Is there any reason this is not used on Unix, instead of the hardcoded subdirectory-of-python_prefix way

Re: [PATCHES] [SQL] ARRAY() returning NULL instead of ARRAY[] resp.

2005-05-31 Thread Joe Conway
Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: + Oid element_type = planstate-ps_ResultTupleSlot-tts_tupleDescriptor-attrs[0]-atttypid; Hmm, that makes me itch ... it seems like unwarranted familiarity with the innards of the subplan; not only as to where

Re: [PATCHES] [HACKERS] Patching dblink.c to avoid warning about

2005-10-07 Thread Joe Conway
Tom Lane wrote: David Fetter [EMAIL PROTECTED] writes: On Thu, Oct 06, 2005 at 10:38:54PM -0400, Bruce Momjian wrote: I don't know if people want this for 8.1 or 8.2. 8.1, IMHO. It's a bug fix. :) Not unless Joe Conway signs off on it ... I had asked on the original simple patch

Re: [PATCHES] [HACKERS] Patching dblink.c to avoid warning about

2005-10-08 Thread Joe Conway
Bruce Momjian wrote: There was also a problem in that if two cursors were opened, the first close would close the transaction. I have fixed that code by changing the xact variable in to a counter that keeps track of the number of opened cursors and commits only when they are all closed. Both

Re: [PATCHES] [HACKERS] Patching dblink.c to avoid warning about

2005-10-15 Thread Joe Conway
Bruce Momjian wrote: No problem -- thanks. I have slimmed down the patch by applying the cosmetic parts to CVS. Use the URL above to get the newest versions of the dblink.c and regression changes. Here is my counter-proposal to Bruce's dblink patch. Any comments? Is it too late to apply

Re: [PATCHES] [HACKERS] Patching dblink.c to avoid warning about

2005-10-16 Thread Joe Conway
Tom Lane wrote: I think it would be shorter and clearer to write remoteConn *remconn = NULL; ... remconn = rconn; ... remconn-newXactForCursor = TRUE; Also, you might be able to combine this variable with the existing rconn local variable and thus

  1   2   >