Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
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.
I don't th
Joe Conway wrote:
Tom Lane wrote:
(It might be time to change the cache lookup into a hashtable instead of
a simple linear list search...)
I could do that if you want, but do you really think it's worth it? How
long does a linked list have to get before a hash table starts to be a
win (th
Tom Lane wrote:
The latter. By the time you pay the price of a hash lookup, a slightly
longer key is nearly free. (Maybe entirely free, since it might produce
better-distributed hash values.)
OK -- I figured that's what you'd say, so I've already started down that
road.
dynahash only supports f
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
+ * The rules for this resolution are as follows:
+ * 1) if the context type is polymorphic, punt and return type_to_resolve
+ *unchanged
+ * 2) if type_to_resolve is ANYARRAY (polymorphic), then return context_type
+ *if
Tom Lane wrote:
In the second case (where you know actual argument type at a different
position) you must know whether the other position's declared type is
anyarray or anyelement, and you can't assume it's the same as the one at
the position you want to resolve.
I still don't understand why that's
Tom Lane wrote:
If only ANYELEMENT and not ANYARRAY appears in a function declaration,
then it can stand for any type, because only rule 2 applies. (The
difference from ANY is that multiple occurences of ANYELEMENT are all
constrained to stand for the same type.)
Hmmm, I don't remember that nuance
Tom Lane wrote:
> Joe Conway wrote:
2) create hash key using a new structure that includes function oid,
return type, and argument types, and use that for direct lookup.
The latter. By the time you pay the price of a hash lookup, a slightly
longer key is nearly free. (Maybe entirely free, si
Joe Conway wrote:
Compiles clean, and passes all regression tests. I'll look to update the
docs and regression tests as part of my post freeze array/polymorphic
function cleanup.
Oh, almost forgot. I had one question, seen here in
get_function_by_signature()
+ if (!entry_
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 far
Tom Lane wrote:
What I've done instead is not to weaken type checking, but simply to
postpone all checking of the body of a SQL function to runtime if it
has any polymorphic arguments. At runtime, we know the actual types
for the arguments, and we know the actual assigned result type, and
then we
OK, so maybe it is a "hold for 7.5" item, but I think it could be argued
that it is a (relatively simple and safe) fix for a relatively big
deficiency with the recently committed plpgsql polymorphism.
By way of explanation, the new plpgsql polymorphism capability means
that a function can be de
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 f
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
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
t
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 some
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 broadcast)
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 ar
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
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
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
***
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 replace
Bruce Momjian wrote:
Patch applied. Thanks.
There was enough code drift since this patch, that a couple of bugs
materialized.
New items have been added to GucContext and GucSource enums, but of
course they were not added to the corresponding GucContextName[] and
GucSourceName[] arrays in the
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, I
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 an
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
==
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 BEF
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Note that I also changed behavior in that when trigdata->tg_event
doesn't match anything known -- instead of pressing on with a value of
"UNKNOWN" it now throws an "elog(ERROR...". The previous behavior mad
Tom Lane wrote:
BTW, one other stylistic nit: I don't think comments like
/* internal error */
elog(ERROR, "unrecognized OP tg_event: %u", tdata->tg_event);
are really necessary. In the brave new ereport world, any elog(ERROR)
call is an internal error by definitio
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: doc/src/sgml/jd
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
===
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,
Noticed broken markup in ecpg.sgml. Attached patch fixes it. Please apply.
Thanks,
Joe
Index: doc/src/sgml/ecpg.sgml
===
RCS file: /opt/src/cvs/pgsql-server/doc/src/sgml/ecpg.sgml,v
retrieving revision 1.47
diff -c -r1.47 ecpg.sgml
*
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 resen
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
Index:
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
h
Bruce Momjian wrote:
Can someone suggest where to document IS OF, and either document it's
non-standard behavior or supply patch?
Doc patch attached for IS OF. Please apply.
Thanks,
Joe
---
Joe Conway wrote:
Gavin S
The Hermit Hacker wrote:
Since we are in beta, it should be relatively safe to do ... if I were to
scheduale 'shutting down and re-merging' the various modules back into one
big one again for 11pm tonight, would everyone be okay with that? It
would mean that all checkin's have to be done before th
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
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
--
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
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 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 fil
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 y
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 m
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 ligh
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 o
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
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 beh
Tom Lane wrote:
I think there is something wrong with your setup procedures, because
I've never needed such.
The main problem seemed to be that I had --disable-rpath in my configure
script, left over from when I was playing with options used by the RPM
spec file. Once I got rid of that, and start
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 t
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 loos
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 a
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
---(e
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 fea
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 pg_config
Tom Lane wrote:
(More generally, I wonder if AtEOXact_SPI oughtn't be fixed to emit
a WARNING if the SPI stack isn't empty, except in the error case.
Neglecting SPI_finish is analogous to a resource leak, and we have
code in place to warn about other sorts of leaks.)
Is the attached what you had in
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 ---
right
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 the
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 comme
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
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
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
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'
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 h
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/a
David Fetter wrote:
OK. How do I test this? After "make && make check" at the top level,
there is no html or pdf.
first do:
cd doc/src/sgml
See:
http://developer.postgresql.org/docs/postgres/docguide-build.html
HTH,
Joe
---(end of broadcast)---
The attached is the supporting documentation for the read-only GUC
variable changes. Comments?
Thanks,
Joe
Index: doc/src/sgml/catalogs.sgml
===
RCS file: /opt/src/cvs/pgsql-server/doc/src/sgml/catalogs.sgml,v
retrieving revision 2.
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-li
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
! *prefix_const = string_to_bytea_const(match, match_pos);
! *rest_const = string_to_bytea_const(rest, pattlen - match_pos);
I think that should be pattlen - pos not pattlen - match_pos, no?
Yup -- you&#x
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 ---
right
Tatsuo Ishii wrote:
It's surprising that nobody noticed the bug until now. It seems it has
been there since 7.3 days. I would like to make a back patch for
7.3-stable if nobody objects.
It's my bug :( -- sorry about that. Here's a 7.3 patch per Tom's nearby
advice. I'll apply if you'd like.
Joe
I
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
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
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
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 semanti
Claudio Natoli wrote:
[Of course, whether or not this is the best behaviour (as opposed to error)
is an arguable point.]
Thanks for the input. I think I'll go with Tom's nearby advice and make
it an error.
Joe
---(end of broadcast)---
TIP 1: subs
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 ;-). Interest
Tom Lane wrote:
Maybe the best documentation answer is to create a new subsection in the
Functions chapter. This may be our first standard set-returning
function but I bet it will not be the last, so the shortness of the
subsection doesn't bother me.
A first shot at documentation for generate_seri
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
generate_series(
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 o
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 we
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.
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
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
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
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
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; w
Matthew T. O'Connor wrote:
This patch resolves this new found bug and fixes some of the other
debugging output to be more consistent.
Please apply to both HEAD and the 7.4 branch.
Bruce, if you'd like, I'll apply this one. I plan to test it out tonight
or tomorrow.
Thanks,
Joe
-
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.
Resolv
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 inap
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
[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 t
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 broadcast)--
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;
+
+
Andrew Dunstan wrote:
I also got the rpath test sense wrong in the make file fix. It should read
(assuming this mailer dowsn't break lines badly):
ifeq ($(enable_rpath), yes)
SHLIB_LINK = $(perl_embed_ldflags) $(BE_DLLLIBS)
-Wl,-rpath,$(perl_archlibexp)/CORE
else
SHLIB_LINK = $(perl_embed_ldflags)
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 there
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
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 obje
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
[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: subscrib
1 - 100 of 196 matches
Mail list logo
