Joe Conway wrote:
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
[ improved patch ]
Still a couple quibbles:
[ more good feedback ]
All valid complaints, and noticeably improved/simplified code as a
result. Third patch attached.
Patch applied to HEAD.
Joe
--
Sent via
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
[ improved patch ]
Still a couple quibbles:
[ more good feedback ]
All valid complaints, and noticeably improved/simplified code as a
result. Third patch attached.
Joe
Index: db
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Here is my proposed patch -- as suggested for cvs tip only.
A few comments:
[...great comments as usual...]
Thanks for the excellent feedback! I think the attached addresses it all.
I haven't been around enough lately t
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Yeah, the dblink code should probably try a bit harder to propagate the
original error fields.
Sounds reasonable. Do you think this is a bug fix or an 8.4 enhancement?
8.4 enhancement I think, since a behavioral
Alvaro Herrera wrote:
Merlin Moncure escribió:
Yesterday, we notified -hackers of the latest version of the libpq
type system. Just to be sure the right people are getting notified,
we are posting the latest patch here as well. Would love to get some
feedback on this.
I had a look at this pa
Bruce Momjian wrote:
Joe, are you nearly ready to apply this?
Done (head and backwards to 7.3).
Joe
---(end of broadcast)---
TIP 6: explain analyze is your friend
Bruce Momjian wrote:
Joe, are you nearly ready to apply this?
Yeah, sorry for the delay. By the end of the weekend.
Joe
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Joe Conway wrote:
Tom Lane wrote:
A couple of minor thoughts:
* You could reduce the ugliness of many of the tests by introducing a
variant strcmp function that does the "right" things with NULL inputs.
It might also be worth adding a variant pstrdup that takes a NULL.
I had thou
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Well, maybe the attached patches better explain what I mean.
In the case of the 8.2 patch, a very small code change allows new
regression data including NULL rowids to:
1) not crash
2) have no impact otherwise
The much
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
1. Treat NULL rowid as a category in its own right. This would conform
with the behavior of GROUP BY and DISTINCT, for instance.
In any case, the attached changes the behavior to #1 for both flavors of
crossta
Oops, just noticed I sent this to the General list instead of Patches --
sorry about that.
Joe
Original Message
Subject: Re: [GENERAL] Crosstab Problems
Date: Wed, 24 Oct 2007 19:26:16 -0700
From: Joe Conway <[EMAIL PROTECTED]>
To: Tom Lane <[EMAIL PROTECTED]>
CC:
Gregory Stark wrote:
"Joe Conway" <[EMAIL PROTECTED]> writes:
Stephen Frost wrote:
* Joe Conway ([EMAIL PROTECTED]) wrote:
There are none installed by default -- that's the point.
Uhh... None what? Functions in untrusted languages? That's certainly
not the cas
Stephen Frost wrote:
It's about as good as saying "Well, an admin had to install PostgreSQL
on the system, by choice, and therefore we don't need to worry about PG
allowing someone remote shell access to the system".
That's a ridiculous assertion -- I said nothing of the sort.
Joe
---
Stephen Frost wrote:
* Joe Conway ([EMAIL PROTECTED]) wrote:
There are none installed by default -- that's the point.
Uhh... None what? Functions in untrusted languages? That's certainly
not the case, there's a whole slew of them, from boolin to
generate_series and b
Stephen Frost wrote:
* Joe Conway ([EMAIL PROTECTED]) wrote:
Sure it matters. A function written in a trusted language is known to be
safe, a priori. A function written in an untrusted language has no such
guarantees, and therefore has to be assumed unsafe unless carefully proved
otherwise
Stephen Frost wrote:
* Joe Conway ([EMAIL PROTECTED]) wrote:
Consider a scenario like "package uses untrusted language z>". Exact same concerns arise.
No, it doesn't... Said arbitrary function in y, in untrusted language
z, could be perfectly safe for users to call.
Gregory Stark wrote:
Consider a scenario like "package uses dblink". Sysadmin follows
instructions for package and installs dblink. Now package 's
documentation isn't going to explain the second-order effects and discuss
restricting who has access to dblink. The sysadmin has no particular inter
Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> writes:
My objection is that I think we should still revoke access for non-superuser
by default. The patch makes granting execute reasonable for most users but
nonetheless it shouldn't be the default.
Being able to connect to a postgres server
Joe Conway wrote:
I'm working on the back branch solution now.
Attached is for back-patching. I left in the SECURITY DEFINER functions
and dblink doc changes -- even though they may not do existing
installations much good, I think there will still be enough new 8.2.x
installations
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Attached patch implements this proposal, including documentation
changes. I'll work separately on the back-branch version.
Any comments/objections?
Looks OK in a fast scan, except that you are not following the message
style
Tom Lane wrote:
Here's a straw-man proposal that we could perhaps do for 8.3:
1. Invent a libpq connection-status function
bool PQconnectionUsedPassword(const PGconn *conn);
This returns true if the server had demanded a password during the
authentication phase. Aside from solving the
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
What about using the attached for 8.3, as well as earlier?
It simply does not allow the local database user to become someone else
on the libpq remote connection unless they are a superuser.
This assumes that usernames on the
Tom Lane wrote:
Here's a straw-man proposal that we could perhaps do for 8.3:
What about using the attached for 8.3, as well as earlier?
It simply does not allow the local database user to become someone else
on the libpq remote connection unless they are a superuser. As Tom
noted, a simple
Joe Conway wrote:
Robert Treat wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Well certainly dbi-link has the exact same issue.
dbi-link only works in plperlu, so you've already decided your superuser only.
How so -- it is fundamentally no different than dblink, which is C
lan
Robert Treat wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Well certainly dbi-link has the exact same issue.
dbi-link only works in plperlu, so you've already decided your superuser only.
How so -- it is fundamentally no different than dblink, which is C
language (also untr
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Would it be sensible to change dblink so that unless invoked by a
superuser, it fails any connection attempt in which no password is
demanded? I am not sure that this is possible without changes to libpq;
but ig
Tom Lane wrote:
Stephen Frost <[EMAIL PROTECTED]> writes:
* Magnus Hagander ([EMAIL PROTECTED]) wrote:
Kerberos is not affected either, because the server does not get a copy
of the ticket. In theory it could be affected if the server requested a
delegation enabled ticket, and exported it so it
Tom Lane wrote:
Robert Treat <[EMAIL PROTECTED]> writes:
Did you mean s/trust/ident/g, otherwise I don't think I understand the
above...
Both trust and ident local auth are sources of risk for this, although
ident is particularly nasty since the DBA probably thinks he's being
secure.
For that
Robert Treat wrote:
Patch based on recent -hackers discussions, it removes usage from public, and
adds a note to the documentation about why this is neccessary.
I agree with the fix as the simplest and most sensible approach, and in
general with the doc change, but I'm not inclined to refere
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
Attached is a patch that makes a minor addition to the StringInfo API:
resetStringInfo(), which clears the current content of the StringInfo
but leaves it valid for future operations.
I needed this for an external project, but ISTM this
Joe Conway wrote:
Sorry for the delay. I've done some rework to the original code sent by
Kai, mainly to reduce duplication with the existing synchronous case,
and to better fit with the existing docs, regression script, etc. I also
changed the return type of dblink_get_connections() to
Joe Conway wrote:
I just received this (offlist), and have not had a chance to review it
myself yet, but figured I should post it now in case others want to have
a look and comment or discuss before feature freeze.
If there are no major objections to the concept, I'll take
responsibili
Tom Lane wrote:
Yeah, I've just been doing that and some hand analysis too. What I get
(on a 64-bit machine) is that essentially all the space goes into
lists of A_Const lists: 32000
lists of Const lists: 32000
transformInsertRow extra lists: 14400
I think we coul
Tom Lane wrote:
I wonder whether there is any reasonable way to determine which data
structures are responsible for how much space ... in my test I'm seeing
MessageContext: 822075440 total in 104 blocks; 4510280 free (1 chunks);
817565160 used
ExecutorState: 8024624 total in 3 blocks; 20592 fr
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
This patch retains the memory consumption savings but doesn't break any
regression tests...
I'm unconvinced that retail pfree's are the way to go. I just did some
profiling of this test case:
It's slight
Joe Conway wrote:
Tom Lane wrote:
Here's what I've got so far. I think there's probably more gold to be
mined in terms of reducing runtime memory consumption (I don't like the
list_free_deep bit, we should use a context), but functionally it seems
complete.
I checked o
Tom Lane wrote:
Here's what I've got so far. I think there's probably more gold to be
mined in terms of reducing runtime memory consumption (I don't like the
list_free_deep bit, we should use a context), but functionally it seems
complete.
I checked out memory usage, and it had regressed to ab
Tom Lane wrote:
Here's what I've got so far. I think there's probably more gold to be
mined in terms of reducing runtime memory consumption (I don't like the
list_free_deep bit, we should use a context), but functionally it seems
complete. I'm off to dinner again, it's in your court to look ove
Gavin Sherry wrote:
Is this intentional:
template1=# values(1), (2);
column1
-
1
2
(2 rows)
This is legal because of:
simple_select:
/* ... */
| values_clause { $$ = $2; }
hmm, not sure about that...
Also, I am working out
Tom Lane wrote:
Here's what I've got so far. I think there's probably more gold to be
mined in terms of reducing runtime memory consumption (I don't like the
list_free_deep bit, we should use a context), but functionally it seems
complete. I'm off to dinner again, it's in your court to look ove
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
I wanted to post an updated patch even though there are still things not
working again after conversion to bare expressions.
I've been through the planner part of this and it looks OK (one or two
small errors). I'm c
Tom Lane wrote:
As far as avoiding overhead goes, here's what I'm thinking:
* The Values RTE node should contain a list of lists of bare
expressions, without TargetEntry decoration (you probably do not
need ResTarget in the raw parse tree for VALUES, either).
* The ValuesScan plan node will jus
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
I'm afraid though that after 2 or so days heading down the last path you
suggested (namely making a new jointree leaf node) I was having trouble,
and at the same time came to the conclusion that adding a new RTE was
alot clean
Joe Conway wrote:
Tom Lane wrote:
I thought Joe was off in a corner doing a whole new version.
(I'm willing to help if he needs help...)
Yeah, I was going to post the latest tonight.
Sorry for the delay. Ever see the movie "The Money Pit"? This afternoon
I started to think
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Are you going to apply this? Seems it is ready.
I thought Joe was off in a corner doing a whole new version.
(I'm willing to help if he needs help...)
Yeah, I was going to post the latest tonight.
I'm afraid though that after 2 or
Tom Lane wrote:
ISTM that this should be represented using an RTE_SUBQUERY node in the
outer query; the alias attaches to that node, not to the VALUES itself.
So I don't think you need that alias field in the jointree entry either.
If we stick with the plan of representing VALUES as if it were S
I just received this (offlist), and have not had a chance to review it
myself yet, but figured I should post it now in case others want to have
a look and comment or discuss before feature freeze.
If there are no major objections to the concept, I'll take
responsibility to review and commit once
Tom Lane wrote:
There are basically two ways you could go about this:
1. Make a new jointree leaf node type to represent a VALUES construct,
and dangle the list of lists of expressions off that.
2. Make a new RangeTblEntry type to represent a VALUES construct, and
just put a RangeTblRef to it i
Joe Conway wrote:
Since the feature freeze is only about a week off, I wanted to post this
patch even though it is not yet ready to be applied.
Sorry -- I just realized that two new files for ValuesScan didn't make
it into the patch posted earlier. Here they are now -- please untar in
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
I'm liking this too. But when you say "jointree node", are you saying to
model the new node type after NestLoop/MergeJoin/HashJoin nodes? These
are referred to as "join nodes" in ExecInitNode. Or as y
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
Strange. Last time I checked I thought MySQL dump used 'multivalue
lists in inserts' for dumps, for the same reason that we use COPY
I think Andrew identified the critical point upthread: they don't try
to put an unlimited n
Andrew Dunstan wrote:
Christopher Kings-Lynne wrote:
The major downside is that somewhere between 9000 and 1
VALUES-targetlists produces "ERROR: stack depth limit exceeded".
Perhaps for the typical use-case this is sufficient though.
I'm open to better ideas, comments, objections...
I
Joe Conway wrote:
. multiple values clauses for INSERT
The best way might be to fabricate a selectStmt equiv to
"SELECT UNION ALL SELECT ...",
but that still feels like a hack.
Here is a patch pursuant to my earlier post. It has the advantage of
being fairly simple and noninvas
Joe Conway wrote:
I just noticed this warning:
gcc -O -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g
-pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic
-DFRONTEND -I. -I../../../src/include
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Should I just accept that the cursor advances on a row type mismatch
error, fix using the attached patch and adding SCROLL to dblink_open(),
or something else? Any opinions out there?
I would go with accepting (and documentin
Joe Conway wrote:
Joe Conway wrote:
However, there is a remaining oddity with dblink_fetch(). Basically,
each time dblink_fetch() is called, the named cursor is advanced, even
though an error is thrown before returning any rows. Is there a simple
way to get the number of columns in the result
Joe Conway wrote:
However, there is a remaining oddity with dblink_fetch(). Basically,
each time dblink_fetch() is called, the named cursor is advanced, even
though an error is thrown before returning any rows. Is there a simple
way to get the number of columns in the result, without actually
Akio Iwaasa wrote:
The following bug has been logged online:
Bug reference: 2129
Logged by: Akio Iwaasa
"postgres" process terminated with "signal 11"
because of my wrong SQL statement using "dblink".
--- SQL statement(Select statement a function) ---
select into RET *
fr
Bruce Momjian wrote:
Joe Conway wrote:
Thanks for the review Tom -- as usual, great suggestions. The attached
(simpler) patch makes use of your advice. If there are no objections,
I'll apply this tomorrow evening.
Looks good. Thanks.
Committed.
Joe
---(e
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 simpl
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 thi
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 th
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 origi
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 subpl
Joe Conway wrote:
OK, looks like I'm outnumbered.
But as far as I know, we have never had a way to produce a
one-dimensional empty array. Empty arrays thus far have been dimensionless.
Assuming we really want an empty 1D array, I created the attached patch.
This works fine, but now lea
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
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
Neil Conway wrote:
Barring any objections, I'll apply the patch within 24 hours.
***
*** 965,978
* (including any overhead such as escaping backslashes), and detect
* whether each item needs double quotes.
*/
! values = (char **) palloc(nitems * si
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
s
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: /cvsroot/pgsql-server/src
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
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 unsubscrib
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 d
Tom Lane wrote:
I had pretty much come to the conclusion that the array_in code should
be thrown away and rewritten from the ground up --- whoever wrote it
originally had no calling as a programmer :-(. I didn't look at the
details of your patch, but I have little faith in half measures in this
ar
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 r
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
If there are no objections, I'll adjust the appropriate regression
script/expected files and commit tonight. And of course I'll follow up
with documentation updates too.
BTW, I believe the plan is to wrap 8.0beta1 tomorrow,
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
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.p
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' a
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 p
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
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
[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
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
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:
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
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:
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:
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:
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)--
[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
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
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
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
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
-
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
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
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:
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
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
1 - 100 of 196 matches
Mail list logo
