John Hansen wrote:
Applied, with changes to allow srand and disallow sprintf, as per
subsequent discussion.
How about allowing:
use utf8;
use locale;
?
I think it is *way* too late in the dev cycle to be proposing this.
Maybe it should be a TODO item - I at least don't have time even to
That attached patch updates the docs for COPY CSV to include the
recently discussed limitation on importing data with embedded line-end
characters.
Maybe we also need a TODO to revisit this during the 8.1 cycle, but I
don't believe we should do more than this for now.
cheers
andrew
Index: doc/
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Why does pg_resetxlog seem top be the only one of our programs that has
no long form options (or at least the only one that calls getopt rather
than getopt_long)? Should we make it consistent with everything else?
I thin
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I take this as confirmation that calling pg_usleep is the Right Thing (tm).
Here's the patch.
Applied.
Darnit, I caught one and not the other. Here's a oneline fix.
cheers
andrew
Index: src/backend/pos
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
I am seeing the following compile warnings in CVS. I am using for perl:
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
I believe these two:
plperl.c:948: warning: `ret_hv' might be used uninitialized in this
Magnus Hagander wrote:
From what I can tell, this XSL will download and import another XSL from
docbook.sourceforge.net every time you run "make" on it. Perhaps a copy
of this file should be included in cvs to make sure we can still build
when sourceforge is down?
Using xsl:import here is not a
Bruce Momjian said:
>
> Uh, what was the TODO here? I forgot.
>
>
John wanted us to allow use of the 'locale' and 'utf8' pragmas in trusted
code. If there's a TODO it would be to investigate the possibility, as I am
very far from certain that there is a simple way to do it safely right now.
Maybe
Korea PostgreSQL Users Group said:
> I found that function gen_salt() in contrib/pgcrypto had bug on win32.
>
> I patched contrib/pgcrypto/random.c file.
>
> --
>
> $ diff random.orig.c random.c
> 42a43
>> #include
> 87a89,90
>> srandom(time(NULL));
>>
> 89c92
> < *
Korea PostgreSQL Users' Group wrote:
I found that function gen_salt() in contrib/pgcrypto had bug on win32.
I patched contrib/pgcrypto/random.c file.
What is the purpose of this addition?
+ srandom(time(NULL));
+
Is resetting the seed on each call a good idea?
cheers
andrew
Andrew Dunstan wrote:
Peter Eisentraut wrote:
I seem to recall that there is a bug in the FreeBSD shell with line
breaks in traps. Try changing the above to
trap 'st=$?; echo status = $st; exit $st' 0
Thankyou Peter! I'd never have guessed something so obscure!
I have conf
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I guess we could put a small sleep before dropdb in pg_regress.sh to
I'd prefer to put it in contrib/Makefile's installcheck rule, so that
we don't pay the price in contexts where it's not needed.
I was egtting a compile error complaining (in effect) abour the lack of
a pid_t type when attempting a compile with MSVC. The attached patch,
which move the definition up in the file win32.h before it is used,
seems to cure the problem.
I am also seeing non-fatal warnings about redefinition of
Andrew Dunstan wrote:
I am also seeing non-fatal warnings about redefinition of SIG_ERR
SIG_DFL and SIG_IGN which I will investigate.
The cure for this seems to be to add
#include
near the top of src/include/port/win32.h.
cheers
andrew
---(end of broadcast
Attached is a makefile I hacked up to build pg_config under MSVC - the
reason is that it's required (more or less) in order to build the latest
DBD::Pg code and I was testing that out under MSVC. Should be saved as
src/bin/pg_config/win32.mak if we're to be consistent. I haven't yet
done a patc
The attached patch allows MSCV builds to complete.
The warnings still shown (see recent -hackers email) are identical to
those that were present in RC2, so they are not the products of recent
homedir changes.
cheers
andrew
Index: interfaces/libpq/fe-connect.c
===
Magnus Hagander wrote:
The attached patch allows MSCV builds to complete.
Applied.
(I wonder whether the Borland build still works...)
I'm sure it still eneds the shell32 linking. The suorce part should be
the same - AFAIK they ship the MS headers. But I don't have a way to
test it, so
The recent change to pg_regress.sh has apparently broken testing on my
Windows machine - see
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=loris&dt=2005-01-15%2001:36:36
which contains this:
== pgsql.2544/src/test/regress/log/postmaster.log
===
LOG: could n
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The recent change to pg_regress.sh has apparently broken testing on my
Windows machine - see
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=loris&dt=2005-01-15%2001:36:36
which contains this:
Y'know, I wonde
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
What about the Cygwin port --- will it have the same issue? If so what
should we add?
No, Cygwin works OK - still have occasional issues with non-empty
tablespaces, but not this issue. The
Tom Lane said:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> Hm --- have you checked it since I changed the script?
>
>> yes. See
>> http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=gibbon&br=HEAD
>
> [ scratches head
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
Tom Lane said:
[ scratches head... ] Why isn't the #undef in pg_config_manual.h
firing on Cygwin?
But on Cygwin, WIN32 is only defined if windows.h has been included (See
previous discussion - I
Dave Page said:
>
>>
>> Hmm:
>>
>> Windows:
>>
>> VOID Sleep(DWORD dwMilliseconds);
>>
>> Unix:
>>
>> unsigned int sleep(unsigned int seconds);
>>
>> D'oh!
>>
>> Patch coming up
>
We should not be using either of these, should we? pg_usleep() is platform
independent.
cheers
andrew
--
Kris Jurka wrote:
The attached patch implements the soundex difference function which
compares two strings' soundex values for similarity.
ISTM that given how soundex-specific this function is it should have a
less generic name than "difference".
soundex_difference maybe?
cheers
andrew
---
Attached is a proof-of-concept patch (i.e. not intended for application
just yet) to fix the problem of parsing CSV multiline fields.
Originally I indicated that the way to solve this IMHO was to the
combine reading and parsing phases of COPY for CSV. However, there's a
lot going on there and I
Bruce Momjian said:
>
> This thread has been saved for the 8.1 release:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches2
>
>
There have been many such postings. Are we not in the 8.1 dev cycle right
now? And some changes have already been committed to the HEAD branch that
are not or shou
Well, in response to the huge number (0) of comments on my POC patch to
fix this, I prepared the attached patch, which improves on my previous
effort a bit (there was one obscure failure case which is now handled).
Basically, all the required logic is in a new function CopyReadLineCSV()
which i
Bruce Momjian said:
>
> Shame we had to duplicate CopyReadLine() in a sense.
>
>
If you can find a clean way to merge them please do - I'll be very grateful.
My head started to spin when I tried. In general I dislike having more than
2 or 2 levels of logic in a given piece of code.
cheers
andr
Andrew Dunstan wrote:
Bruce Momjian said:
Shame we had to duplicate CopyReadLine() in a sense.
If you can find a clean way to merge them please do - I'll be very grateful.
My head started to spin when I tried. In general I dislike having more than
2 or 2 levels of logic in a given
Neil Conway wrote:
> Bruce Momjian wrote:
>
>> Handle carriage returns and line feeds in COPY CSV mode.
>
>
> Would it be possible to have some regression tests for this?
will this do?
cheers
andrew
Index: src/test/regress/input/copy.source
=
The attached patch implements the previously discussed header line
feature for CSV mode COPY. It is triggered by the keyword HEADER (blame
Bruce - he chose it ;-) ).
On input this feature causes the first line to be ignored; on output it
generates a line of column names. This will make playing w
Alvaro Herrera said:
> On Sun, Mar 13, 2005 at 06:32:20PM -0500, Andrew Dunstan wrote:
>
>> The attached patch implements the previously discussed header line
>> feature for CSV mode COPY. It is triggered by the keyword HEADER
>> (blame Bruce - he chose it ;-) ).
>
>
ammended patch attached. sorry for the oversight. I agree with Tom's
remark - it's far too easy to miss this.
cheers
andrew
Alvaro Herrera wrote:
>On Tue, Mar 15, 2005 at 08:55:36PM -0600, Andrew Dunstan wrote:
>
>
>>Alvaro Herrera said:
>>
>>
>&g
Mark Kirkwood wrote:
> Andrew Dunstan wrote:
>
>> It fixes the build error on Windows - haven't tried because i don't have
>> time, but I know it won't work on Cygwin, because WIN32 isn't (usually)
>> defined on Cygwin - see previous almost end
Michael Fuhr said:
> On Mon, Mar 21, 2005 at 03:02:57AM -0500, Tom Lane wrote:
>>
>> One thing that needs some thought is how you are going to test this
>> robustly. I'd not feel any great deal of confidence in a test that
>> expects that we can push \r\n sequences into CVS and expect them to
>> s
I have confirmed that the attached patch works on Cygwin as well as
Windows. Please apply.
cheers
andrew
Andrew Dunstan wrote:
It fixes the build error on Windows - haven't tried because i don't have
time, but I know it won't work on Cygwin, because WIN32 isn't (usually)
def
Mark Kirkwood wrote:
Neil Conway wrote:
Andrew Dunstan wrote:
I have confirmed that the attached patch works on Cygwin as well as
Windows. Please apply.
Applied, thanks.
Great that it fixes it... however, I had submitted a tidier patch that
puts the macro in the header (probably after
This would explain the similar failure that I reported and didn't get
around to digging into. Excellent.
andrew
Simon Riggs wrote:
I have access to a system with locale of UTF-8. cvstip would no longer
initdb on this system, as a result of recent renaming of UTF-8 to UTF8.
i.e.
[EMAIL PROTECTED]
Tom Lane wrote:
Richard Huxton writes:
Michael Paesold wrote:
I just don't see why non-interactive mode does need such a switch
because there is no way to check if there was an error. So just put two
queries there and hope one will work?
DROP TABLE foo;
CREATE TABLE foo...
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I would far rather see people code explicit markers around statements
whose failure can be ignored. That is, a script that needs this
behavior ought to look like
BEGIN;
\begin_ignore_error
DROP TAB
Is this what broke the regression tests on HEAD?
cheers
andrew
Neil Conway wrote:
Tom Lane wrote:
If the stats collector gets sufficiently backed up, you will lose
messages. [...] Please do not try to make piecemeal changes in that
basic design decision.
Fair enough.
> (Actually, we could skinny
tiny patch to test this feature.
cheers
andrew
Index: input/copy.source
===
RCS file: /home/cvsmirror/pgsql/src/test/regress/input/copy.source,v
retrieving revision 1.11
diff -c -r1.11 copy.source
*** input/copy.source 16 Mar 2005 06:0
Heikki Linnakangas wrote:
On Mon, 9 May 2005, Dennis Bjorklund wrote:
The thing is that I don't care how it's implemented, it's the feature
itself that is more importent to decide if we want it or not. I'm
sure the
code can be fixed so everybody is happy it in the end,
You could implement this o
Abhijit Menon-Sen said:
> At 2005-05-11 10:55:37 +1000, [EMAIL PROTECTED] wrote:
>>
>> > Here is a small patch that implements a function lastval() [...]
>>
>> What do people think of this idea? (Tom seems opposed, I'm just
>> wondering if there are other opinions out there.)
>
> For what it's wort
The attached patch creates installcheck targets for plperl and pltcl
(plpython laready has one). This will help in getting buildfarm to test PLs.
Is it worth rearranging things for plpython so that it follows the same
test layout as the other 2 (i.e. a test subdir with all the test files
and a
Bruce Momjian wrote:
*/
! #ifndef WIN32
! sleep(sleep_secs); /* Unix sleep is seconds */
! #else
! sleep(sleep_secs * 1000); /* Win32 sleep() is milliseconds */
Shouldn't the be Sleep with a capital S? see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/s
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
*/
! #ifndef WIN32
! sleep(sleep_secs); /* Unix sleep is
seconds */
! #else
! sleep(sleep_secs * 1000); /* Win32 sleep() is
milliseconds
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Aha. ok. should be fairly trivial. I'm thinking of something like
--load-languages=lang1,lang2,lang3
(in case we ever want more than one).
Might be a little easier as multiple switches:
--load-language=l
Andrew Dunstan wrote:
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Aha. ok. should be fairly trivial. I'm thinking of something like
--load-languages=lang1,lang2,lang3
(in case we ever want more than one).
Might be a little easier as multiple switches:
--lo
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Ok. Here's a patch for that piece. With this, contrib regression
tests don't load plpgsql, but standard core tests do.
er this time with a patch attached.
Looks good to me, will apply shortly.
Are you
I have just been alerted to a bug in the 8.0 handling of embedded
newlines in CSV data. Basically it barfs on consecutive newlines. The
attached patch for 8.0 appears to fix it. The bug isn't present in the
HEAD branch, and I'm wondering if we should not backpatch the HEAD
multiline patch rathe
Neil Conway wrote:
Andrew Dunstan wrote:
I have just been alerted to a bug in the 8.0 handling of embedded
newlines in CSV data. Basically it barfs on consecutive newlines. The
attached patch for 8.0 appears to fix it. The bug isn't present in
the HEAD branch, and I'm wondering if
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Is that what you had in mind?
Not entirely. We should move around the test sql script and the expected
result file so that the file structure looks exactly like one of the
test-enabled contrib modules.
That's prett
ndrew
|
---
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Is that what you had in mind?
Not entirely. We should move around the test sql script and the expected
result file so that the file structure looks exactly like one of the
test-enabled contrib modules.
Peter Eisentraut wrote:
Tom Lane wrote:
It occurs to me that maybe we should just add src/pl to the toplevel
installcheck target, which would make the whole thing pretty
automatic. However, contrib isn't in that target, so maybe the PLs
shouldn't be either. Thoughts?
Contrib isn't built
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I agree. That will also mean that buildfarm members will automatically
start doing the checks (as long as they are set up to build the PLs), so
it would be an extra bonus for me :-)
The only argument I can think of against
Darn ... previously sent to wrong list
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Currently the pg_regress script does "dbname=regression" and then does
everything in terms of $dbname. Would there be any value in providing a
--dbname=foo parameter so that diff
The attached patch (submitted for testing and comment) allows turning on
perl strict mode via a GUC setting for plperl/plperlu. (plplerlu users
would be able to turn it off again, but plperl users would not, I think.
Certainly not straightforwardly at least.
In order to protect legacy code,
While building some better plperl tests today I discovered a horrid bug
(which I regret to say is my fault), present in both 8.0 and HEAD
branches, The attached patch needs to be applied urgently to both
branches, please.
cheers
andrew
Index: plperl.c
=
Neil Conway said:
>
> BTW, in future it would be good to specify the consequences of the bug
> (i.e. beyond "it is horrible"), so committers who don't use pl/perl can
> judge the urgency of the bug.
Yes, sorry. In fact, fortuitously the effects are not disastrous in most
circumstances. Once we t
continuing my quest for better testing ... ;-)
The current plperl regression tests do not test the trigger or shared
data features. The attached new files remedy that:
sql/plperl_trigger.sql
sql/plperl_shared.sql
expected/plperl_trigger.out
expected/plperl_shared.out
The corresponding patch
Neil Conway wrote:
Andrew Dunstan wrote:
The current plperl regression tests do not test the trigger or shared
data features. The attached new files remedy that [...]
Applied to HEAD. Thanks for the patch.
BTW, I noticed that the PL/Perl regression tests are broken for out of
tree
Tom Lane wrote:
psql, pg_dump, etc allow password specification from stdin and from
.pgpass, never on the command line. There is a reason why they are all
designed like that. pg_autovacuum hasn't been studied carefully enough
I guess, because we should never have let a security hole like thi
Alvaro Herrera wrote:
On Sat, May 21, 2005 at 04:04:36PM -0400, Andrew Dunstan wrote:
Andrew,
it works like this:
andrew=# create or replace function foo() returns text language plperl
as $$ $x = 1; return 'hello'; $$;
CREATE FUNCTION
andrew=# select foo();
ERROR: creati
Alvaro Herrera wrote:
Yes, you can register a function as "validator" during language
creation. AFAIR there are no validator functions except SQL and
plpgsql, so you would have to create one for plperl ...
Excellent. We'll definitely work on that. Not having this has annoyed me
(and I'
Tom Lane wrote:
I see that in fact all the PL tests are broken for vpath builds.
Fixed (copy and paste from src/test/regress) --- I can't actually
test the plpython script right now, but it should work the same
as the other two.
Thanks. I have added support for vpath builds to
Bruce Momjian said:
>
> I have generated the following patch that moves postmaster.pid into the
> configuration directory. pg_ctl only knows about the configuration
> directory because it can't read postgresql.conf, so it seems that is
> the right place to move it.
this seems wrong ... wouldn't i
Neil Conway said:
> On Wed, 2005-06-01 at 16:34 -0700, Alon Goldshuv wrote:
>> 1) The patch includes 2 parallel parsing code paths. One is the
>> regular COPY path that we all know, and the other is the improved one
>> that I wrote. This is only temporary, as there is a lot of code
>> duplication
>
Luke Lonergan said:
> Andrew,
>
>> I will be the first to admit that there are probably some very good
>> possibilities for optimisation of this code. My impression though has
>> been that in almost all cases it's fast enough anyway. I know that on
>> some very modest hardware I have managed to loa
Neil Conway said:
> On Sun, 2005-05-22 at 21:25 +0530, Abhijit Menon-Sen wrote:
>> I have attached the following seven patches to address this problem:
>
> Does anyone with the skills to review this (i.e. someone other than me)
> have any comments on this patch?
>
> Otherwise I'll apply it in a day
This has broken the regression tests for plperl - see for example
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=panda&dt=2005-06-04%2021:20:01
That's because, as Abhijit noted in point 4 below, select foo_srf() no
longer works.
At a minimum those calls need to be removed from the regression
Bruce Momjian said:
> Andrew Dunstan wrote:
>>
>>
>> This has broken the regression tests for plperl - see for example
>>
>>
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=panda&dt=2005-06-04%2021:20:01>>
That's because, as Abhijit noted in po
Currently, nonfatal warnings are not trapped (as they should be) by
plperl - the attached small patch remedies that omission, and adds a
small regression test for error and warning output - the new regression
input and expected output are in separate attached files.
cheers
andrew
Index: GN
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Currently, nonfatal warnings are not trapped (as they should be) by
plperl - the attached small patch remedies that omission, and adds a
small regression test for error and warning output - the new regression
input and ex
The attached patch (submitted for comment) is somewhat adapted from one
submitted last October. This allows returning a perl array where a
postgres array is expected.
example:
andrew=# create function blurfl() returns text[] language plperl as $$
andrew$# return ['a','b','c','a"b\c'];
andrew
David Fetter wrote:
In src/backend/utils/adt/arrayfuncs.c there are direct
array-manipulation functions.
And in other places - I had already found that stuff :-) . But a worked
example would help. If it's not available I'll muddle through some time.
In the perlapi docs for perl, there
That attached 2 patches implement a validator function for plperl, and
support for it in createlang.
This has somewhat less utility than do such functions for languages with
stricter compiletime as opposed to runtime requirements, but I still
think it's useful. If this is acceptable I'll pro
I wrote:
The attached patch (submitted for comment) is somewhat adapted from
one submitted last October. This allows returning a perl array where a
postgres array is expected.
example:
andrew=# create function blurfl() returns text[] language plperl as $$
andrew$# return ['a','b','c','a"
Luke Lonergan said:
> I've attached Alon's patch ported to the CVS trunk. It applies cleanly
> and passes the regressions. With fsync=false it is 40% faster loading
> a sample dataset with 15 columns of varied type. It's 19% faster with
> fsync=true.
>
> This patch separates the CopyFrom code in
This was the patch that I took the array processing piece from and
attempted to fix, since it was badly broken. However, I'm not happy
about any of the ways of doing it, and suspect I won't get it done for
8.1. I think we need that piece done before we look at ANYELEMENT/ANYARRAY.
cheers
an
Bruce Momjian wrote:
Do we need a TODO item?
Sure, Maybe two:
. pass arrays natively instead of as text between plperl and postgres
. add support for polymorphic arguments and return types to plperl
cheers
andrew
---(end of broadcast)--
Luke Lonergan said:
>> 4. We should indeed do this for CSV, especially since a lot of the
>> relevant logic for detecting attribute starts is already there for CSV
>> in CopyReadLine. I'm prepared to help you do that if necessary, since
>> I'm guilty of perpetrating that code.
>
> That would be aw
Alon Goldshuv said:
> Andrew,
>
>> 4. We should indeed do this for CSV, especially since a lot of the
>> relevant logic for detecting attribute starts is already there for CSV
>> in CopyReadLine. I'm prepared to help you do that if necessary, since
>> I'm guilty of perpetrating that code.
>
> That
Petr Jelínek said:
>
> Something about patch:
> I added two new guc variables name max_db_connections and
> max_user_connections which can be set by superuser which means it can
> be in main config file or in user/database config.
Is this what is intended by the TODO item? I thought that it was
Bruce Momjian wrote:
I have applied the E'' escape patch to CVS head.
You missed one regression fix: int8-exp-three-digits.out:
== pgsql.26432/src/test/regress/regression.diffs
===
*** ./expected/int8-exp-three-digits.outSun Jun 26 02:04:42 2005
-
Andrew Dunstan wrote:
Why --- what else is needed beyond the addition of those clauses to the
one query?
There are tests for both the function and the handler based on
finfo->dobj.namespace->dump that inhibit output if we're in the
catalog schema.
If we go down this pa
AgentM said:
> Attached is a patch which corrects the behavior. I verified that the
> patch does not interfere with normal operation (using psql) but
> unfortunately the code path is virtually impossible to test without a
> really slow connection to a postgresql server [which I thankfully
> don't h
Luke Lonergan wrote:
Yah - I think I fixed several mis-indented comments. I'm using vim with
tabstop=4. I personally don't like tabs in text and would prefer them
expanded using spaces, but that's a nice way to make small formatting
changes look huge in a cvs diff.
You might like to lo
I'm very glad to see this. But is a nicer name possible? To perl
programmers at least, "substitute" should make sense.
cheers
andrew
Atsushi Ogawa wrote:
>I made the patch that implements regexp_replace again.
>The specification of this function is as follows.
>
>regexp_replace(source text, p
Luke Lonergan wrote:
Andrew,
You might like to look at running pgindent (see src/tools/pgindent) over
the file before cutting a patch. Since this is usually run over each
file just before a release, the only badness should be things from
recent patches.
I've attached two patches, o
Luke, Alon
OK, I'm going to apply the patch to my copy and try to get my head
around it. meanwhile:
. we should not be describing things as "old" or "new". The person
reading the code might have no knowledge of the history, and should not
need to.
. we should not have "slow" and "fast" eith
Atsushi Ogawa wrote:
I think that regexp_replace is a good name. It is easy to understand.
I'll go with the flow.
cheers
andrew
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Sergej Sergeev said:
> Bruce Momjian wrote:
>
>>Sergej, are you going to repost this patch?
>>
>>
> Sorry for delaying.
> Yes, I working on it, but I wait for decision about Andrew and Abhijit
> patches.
>
This is the polymorphic types plus perl to pg array patch, right?
I am not working on this
In the course of looking into Larry's buildfarm woes, I found that
Unixware needs this patch on HEAD to build correctly
cheers
andrew
Index: src/backend/utils/adt/timestamp.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/uti
Following up a previous thought I had, yesterday I realised how to
return arays nicely without having to make the plperl programmer aware
of anything. The attached patch allows plperl to return an arrayref
where the function returns an array type. It silently calls a perl
function to stringif
Bruce Momjian said:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > Tom Lane wrote:
>> >> It appears that somebody has changed things so that the -L switches
>> >> appear after the -l switches (ie, too late). I'm too tired to
>> >> investigate now, but my money is on Autoconf 2.59 being the probl
Michael Fuhr wrote:
On Tue, Jul 05, 2005 at 01:14:25PM -0400, Tom Lane wrote:
Aside from minor problems like being broken and undocumented, there is a
more serious question here: is this even the functionality we want?
I'd rather see something akin to PL/pgSQL's RETURN NEXT or PL/Pe
The attached patch moves a plperl sanity check into the correct
position. Performing the check in the existing position allows the call
to go through to perl first, possibly resulting in a SEGV.
cheers
andrew
Index: plperl.c
===
The change below has broken tsearch2. See for example
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=shrew&dt=2005-07-10%2015:02:01
cheers
andrew
Bruce Momjian wrote:
I have applied your patch, with slight adjustments in spacing and
documentation.
Patch applied. Thanks.
[snip]
This is completely the wrong list to ask this question - you need to ask
on the lists at
http://jdbc.postgresql.org/lists.html
cheers
andrew
[EMAIL PROTECTED] wrote:
Hi,
I use PostgreSQL 8.0.3 and following associated drivers :
postgresql-8.0-311.jdbc2.jar
postgresql-8.0-311.jdbc2e
The attached (new) src/test/regress/expected/geometry_9.out, intended
only for the 7.3 stable branch, allows a clean regression pass on my
FC4 box. I called it that to avoid conflicts with other geometry_n files
on later branches.
The attached patch for contrib/seg/segparse.y allows a clean
701 - 800 of 941 matches
Mail list logo
