Robert Treat <[EMAIL PROTECTED]> writes:
> I get the following error during make (configure runs fine)
BTW, on re-reading that, it seems a tad surprising to get an error right
there --- if postgres_fe.h or anything it includes were broken, then the
build should have failed earlier. Is the failure
On 9/5/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
> > Am I on the right page?
>
> Got it in one, I believe.
In that case, +1 for your proposed changes.
At first, like Florian, I found the idea of a SET LOCAL ever
persisting beyond a function astonishing,
Robert Treat <[EMAIL PROTECTED]> writes:
> I get the following error during make (configure runs fine)
> /usr/include/netdb.h:560: error: syntax error before =E2=80=98[=E2=80=99 to=
> ken
Which line of netdb.h is that exactly? I'm thinking we've redefined
some name as a macro that's breaking the
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> So, if I read you correctly, in summary we'd like to:
> * make SET LOCAL local to the transaction (i.e., make it behave as
> documented),
> * abandon the idea of a subtransaction-local SET, because the new
> function-local SET takes care of the inter
Trying to build 8.3 from the stable snapshot again (yes, I'm a glutten for
punishment), and using the following config options:
./configure --prefix=/home/rob/devel/postgresql/83snapshot20070904/pgsql/
--enable-cassert --with-perl --enable-debug --with-pgport=5483 --with-libxml
I get the follow
On Sep 4, 2007, at 8:55 PM, korry.douglas wrote:
Sorry about that John, there's a fix for this problem (it's an 8.2
versus 8.3 issue) in the CVS repository. I thought I had rolled a
new tarball after committing the fix but I guess not.
You can pull the latest plugin_profiler.c from:
Tha
"Josh Berkus" <[EMAIL PROTECTED]> writes:
> Who are we, MySQL? We ought not to accept the syntax if we're not going
> to enforce it.
I think the thinking is that the syntax doesn't promise anything about
enforcing any restrictions. It's a method for the user to declare what
features he needs.
The core of the debugger has been in use for quite some time, but I
had to strip out a lot of EDB-specific code and I'd like to see that
the result (the open-source version at pgFoundry) holds up well on
other platforms.
Josh, any chance you could try it out on Solaris?
I copied the latest
Heikki,
> FOR READ ONLY is actually part of the SELECT syntax. It's been accepted
> for at least down to version 7.4, probably even longer than that, but it
> hasn't been documented. It's accepted for the sake of compatibility with
> other DBMSs (and SQL standard?), it doesn't do anything in Postg
On Sep 4, 2007, at 1:01 PM, korry.douglas wrote:
The core of the debugger has been in use for quite some time, but I
had to strip out a lot of EDB-specific code and I'd like to see
that the result (the open-source version at pgFoundry) holds up
well on other platforms.
Josh, any chance you
Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > On Tue, Sep 04, 2007 at 01:22:01PM -0400, Tom Lane wrote:
> >> ... The only reason I can see to
> >> use these options today is if you want to try to port the dump to
> >> some other database ... and in that case you probably shouldn't
Josh Berkus wrote:
> Dave,
>
> > Or maybe in second thought Korry was actually referring the Information
> > Week article...
>
> Yeah, I think so. The PL/pgSQL debugger was part of a list of 14-15 features
> I gave Charles Babcock; not sure why he liked that one, but he did.
Yea, it is very ha
Gregory Stark wrote:
> Devrim G?ND?Z <[EMAIL PROTECTED]> writes:
>
> > On Tue, 2007-09-04 at 10:07 -0400, korry.douglas wrote:
> >> Now that we've "announced"
> >
> > Could you please define "we"? Is it "EDB" or "PostgreSQL" ? I'm asking
> > this per a thread @ -advocacy list.
>
> It looks like
korry.douglas wrote:
Don't see the tracer, unless I'm missing what you mean.
You're right, it's not in the edb-debugger tarball. If you think you
might be interested, I can resurrect it.
Hmm - it's not that the plpgsql I write has complex control-flows, but
it might prove useful to others.
Greg,
> As far as I'm concerned, that function of the background writer has been
> replaced by the load distributed checkpoint features now controlled by
> checkpoint_completion_target, which is believed to be a better solution
> in several respects. I'm been trying to motivate people happily usi
Korry,
> If by "ready to go" you mean "has been tested by a few people and
> compiled on a few platforms", that's where we are now - I would like to
> see some more testing (especially on platforms other than Windows,
> Linux, and OS X).
Well, if we don't publicize it at least a little, nobody wi
korry.douglas wrote:
Do we know if it going to be distributed with pgAdmin on Windows?
The graphical debugger client is part of pgAdmin (on all platforms I
believe - Dave Page can say for sure).
Yes, it's fully integrated and supported on all platforms supported by
pgAdmin.
I don't know if
korry.douglas wrote:
Looks great, and I'll be testing it shortly, but can I ask:
1. For 8.3 are we talking pgFoundry / contrib / core?
The server side of the debugger is implemented as a contrib module, but
not distributed with the PG core. You have to get it from pgFoundry,
untar it (which
The interview made it sound more mainstream. But then it did sound a
little disjointed too.
I suspect that it may go more mainstream in a later release, but it
seems way too late for 8.3.
Do we know if it going to be distributed with pgAdmin on Windows?
The graphical debugger client is part of
On 9/5/07, Michael Paesold <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
> > Basically my perspective on SET LOCAL is that its current behavior is a
> > bug, and even though it's been that way for a couple major releases now,
> > it's still something we oughta fix while we are busy whacking that par
Tom Lane wrote:
David Fetter <[EMAIL PROTECTED]> writes:
On Tue, Sep 04, 2007 at 01:22:01PM -0400, Tom Lane wrote:
... The only reason I can see to
use these options today is if you want to try to port the dump to
some other database ... and in that case you probably shouldn't
assume
Apologies - new list user, hit reply not reply all :-/
korry.douglas wrote:
Yeah, I think so. The PL/pgSQL debugger was part of a list of 14-15
features I gave Charles Babcock; not sure why he liked that one, but
he did.
Last I talked to Korry, it was ready to go. No?
If by "ready to
David Fetter <[EMAIL PROTECTED]> writes:
> On Tue, Sep 04, 2007 at 01:22:01PM -0400, Tom Lane wrote:
>> ... The only reason I can see to
>> use these options today is if you want to try to port the dump to
>> some other database ... and in that case you probably shouldn't
>> assume multi-insert wil
Andrew Dunstan wrote:
>
> I would like to add an argument to pg_regress that allows us to set some
> config options for the temp install. Specifically right now I am
> interested in setting the following:
>
> log_line_prefix = '[%c] '
> log_statement = 'all'
> log_connections = 'true'
>
> But
I would like to add an argument to pg_regress that allows us to set some
config options for the temp install. Specifically right now I am
interested in setting the following:
log_line_prefix = '[%c] '
log_statement = 'all'
log_connections = 'true'
But I think it makes more sense to provid
On Tue, Sep 04, 2007 at 01:22:01PM -0400, Tom Lane wrote:
> =?iso-8859-15?q?C=E9dric_Villemain?= <[EMAIL PROTECTED]> writes:
> > Well, I can only make a new ask. Why is there the --inserts and
> > --attribute-inserts options ?
>
> It's mostly historical IMHO. The COPY option used to have bugs fo
=?iso-8859-15?q?C=E9dric_Villemain?= <[EMAIL PROTECTED]> writes:
> Well, I can only make a new ask.
> Why is there the --inserts and --attribute-inserts options ?
It's mostly historical IMHO. The COPY option used to have bugs for
corner cases like inheritance child tables that had been ALTERed af
Le mardi 4 septembre 2007, Tom Lane a écrit :
> =?utf-8?q?C=C3=A9dric_Villemain?= <[EMAIL PROTECTED]> writes:
> > In order to make some trivial test, I have start patching pg_dump to
> > get=20 insert using multi-rows (like --inserts option).
>
> Why? COPY is faster and won't have issues for very
Yeah, I think so. The PL/pgSQL debugger was part of a list of 14-15 features
I gave Charles Babcock; not sure why he liked that one, but he did.
Last I talked to Korry, it was ready to go. No?
If by "ready to go" you mean "has been exercised by a mess o' people", no.
If by "ready to go"
=?utf-8?q?C=C3=A9dric_Villemain?= <[EMAIL PROTECTED]> writes:
> In order to make some trivial test, I have start patching pg_dump to get=20
> insert using multi-rows (like --inserts option).
Why? COPY is faster and won't have issues for very large numbers of
rows.
regards
Hello,
In order to make some trivial test, I have start patching pg_dump to get
insert using multi-rows (like --inserts option).
I say "start" because it was just a poor hack to pg_dump.c.
If you are interested I can finish it, and try to get a code that feet
postgresql guidelines ?
--
Cédri
Pavel Stehule wrote:
>> 1) In-context debugging: you set a breakpoint on a function (from within a
>> tool like pgAdmin) and then invoke that function from some other client
>> application
>
> I mean method 1. I hadn't success with pgAdmin. Breakpoints was ignored.
That normally means the debugge
Josh Berkus wrote:
> Dave,
>
>> Or maybe in second thought Korry was actually referring the Information
>> Week article...
>
> Yeah, I think so. The PL/pgSQL debugger was part of a list of 14-15 features
> I gave Charles Babcock; not sure why he liked that one, but he did.
>
> Last I talked to
On 9/4/07, Tom Lane <[EMAIL PROTECTED]> wrote:
[...]
> But on further thought it strikes me that insisting on all lower case
> doesn't eliminate case-sensitivity portability problems. For instance,
> suppose the given parameter is 'foo' and the actual file name is
> Foo.dict. This will work fine
2007/9/4, korry.douglas <[EMAIL PROTECTED]>:
>
>
>
> 1. can be integrated into psql?
>
> There is an API - I wouldn't want to try to use it from the command-line,
> but you certainly can. You would call functions such as:
> SELECT * FROM pldbg_set_breakpoint( 'myfunction' );
> SELECT *
Dave,
> Or maybe in second thought Korry was actually referring the Information
> Week article...
Yeah, I think so. The PL/pgSQL debugger was part of a list of 14-15 features
I gave Charles Babcock; not sure why he liked that one, but he did.
Last I talked to Korry, it was ready to go. No?
-
1. can be integrated into psql?
There is an API - I wouldn't want to try to use it from the
command-line, but you certainly can. You would call functions such as:
SELECT * FROM pldbg_set_breakpoint( 'myfunction' );
SELECT * FROM pldbg_wait_for_breakpoint( ... );
SELECT * FROM pldb
Pavel Stehule wrote:
> Hello Korry
>
> I test it and with pgAdmin and sent some bug reports (pgAdmin had some
> problems not debugger).
>
Did you report the issues you had? I don't recall seeing anything.
> 1. can be integrated into psql?
Not without significant effort I would imagine - it's t
Devrim GÜNDÜZ <[EMAIL PROTECTED]> writes:
> On Tue, 2007-09-04 at 10:07 -0400, korry.douglas wrote:
>> Now that we've "announced"
>
> Could you please define "we"? Is it "EDB" or "PostgreSQL" ? I'm asking
> this per a thread @ -advocacy list.
It looks like We == Bruce. EDB isn't mentioned in th
2007/9/4, Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
> > 2007/9/4, Tom Lane <[EMAIL PROTECTED]>:
> >> Yeah, good point. So far it seems that a-z 0-9 and underscore cover the
> >> real use-cases, so what say we just allow those for now? It's a lot
> >> easier to lo
In any case, it's a plugin for PostgreSQL 8.2 and above that allows
you to debug pl/pgsql functions using pgAdmin.
Yes I know and spent a bit time for testing it -- but not much.
Devrim, does that mean that you've tried it and it seemed to work? Did
you try it with 8.2 or 8.3?
Hello Korry
I test it and with pgAdmin and sent some bug reports (pgAdmin had some
problems not debugger).
Is it available without pgAdmin? Debugger works well, but integration
with pgAdmin is knotty now. Some points
1. can be integrated into psql?
2. can be started from query execution (with b
Tom Lane wrote:
Michael Paesold <[EMAIL PROTECTED]> writes:
I don't think it's a very good idea to make SET TRANSACTION an alias for
SET LOCAL, because SET TRANSACTION has already got its own meaning in the
SQL spec - it sets transaction modes.
Yeah --- I'm not sure we could even do it withou
Hi Dave,
On Tue, 2007-09-04 at 15:55 +0100, Dave Page wrote:
> We, EDB. Though I'm not sure it was so much announced as
> mentioned-in-passing in all honesty.
I was referring to the source of the information in that article,
Dave :)
> In any case, it's a plugin for PostgreSQL 8.2 and above that
Now that we've "announced"
Could you please define "we"? Is it "EDB" or "PostgreSQL" ? I'm asking
this per a thread @ -advocacy list.
That -advocacy thread is what got me started. I was referring to the
interview in InformationWeek - that's a PG-related interview not an
EDB-related
Dave Page wrote:
> Devrim GÜNDÜZ wrote:
>> Hi Korry,
>>
>> On Tue, 2007-09-04 at 10:07 -0400, korry.douglas wrote:
>>> Now that we've "announced"
>> Could you please define "we"? Is it "EDB" or "PostgreSQL" ? I'm asking
>> this per a thread @ -advocacy list.
>
> We, EDB. Though I'm not sure it w
Devrim GÜNDÜZ wrote:
> Hi Korry,
>
> On Tue, 2007-09-04 at 10:07 -0400, korry.douglas wrote:
>> Now that we've "announced"
>
> Could you please define "we"? Is it "EDB" or "PostgreSQL" ? I'm asking
> this per a thread @ -advocacy list.
We, EDB. Though I'm not sure it was so much announced as
m
Michael Paesold <[EMAIL PROTECTED]> writes:
> Florian G. Pflug wrote:
>> Hm... could we still have "SET TRANSACTION" as a synonym for "SET LOCAL"?
>> That would blend nicely with "SET TRANSACTION ISOLATION LEVEL" and
>> "SET TRANSACTION READ ONLY".
> I don't think it's a very good idea to make SET
Ugaa...Sorry I don't have the margin of time.:-(
However, I examined it as EDB
Regards,
Hiroshi Saito
From: "Guillaume Lelarge" <[EMAIL PROTECTED]>
korry.douglas a écrit :
Now that we've "announced" (see
http://www.informationweek.com/news/showArticle.jhtml?articleID=201803375&subSection=
korry.douglas a écrit :
> Now that we've "announced" (see
> http://www.informationweek.com/news/showArticle.jhtml?articleID=201803375&subSection=News)
> that 8.3 will include a debugger (don't worry, it's a PL/pgSQL debugger
> :-), has anyone actually tried it yet (other than myself and Dave Page)?
Hi Korry,
On Tue, 2007-09-04 at 10:07 -0400, korry.douglas wrote:
> Now that we've "announced"
Could you please define "we"? Is it "EDB" or "PostgreSQL" ? I'm asking
this per a thread @ -advocacy list.
Cheers,
--
Devrim GÜNDÜZ
PostgreSQL Replication, Consulting, Custom Development, 24x7 suppo
Now that we've "announced" (see
http://www.informationweek.com/news/showArticle.jhtml?articleID=201803375&subSection=News)
that 8.3 will include a debugger (don't worry, it's a PL/pgSQL debugger
:-), has anyone actually tried it yet (other than myself and Dave Page)?
I would appreciate any fee
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2007/9/4, Tom Lane <[EMAIL PROTECTED]>:
>> Yeah, good point. So far it seems that a-z 0-9 and underscore cover the
>> real use-cases, so what say we just allow those for now? It's a lot
>> easier to loosen up later than tighten up ...
> It's system s
>>> On Tue, Sep 4, 2007 at 4:16 AM, in message
<[EMAIL PROTECTED]>, "Heikki Linnakangas"
<[EMAIL PROTECTED]> wrote:
>
> FOR READ ONLY is actually part of the SELECT syntax.
13.1
Function
Define a cursor.
Format
::=
DECLARE [ IN
2007/9/4, Heikki Linnakangas <[EMAIL PROTECTED]>:
> Pavel Stehule wrote:
> > I used dictionaries from fedora core packages
> >
> > hunspell-cs-20060303-5.fc7.i386.rpm
> >
> > then I converted it to utf8 with iconv
>
> Ok, thanks.
>
> Apparently it's a bug I introduced when I refactored spell.c to u
Pavel Stehule wrote:
> I used dictionaries from fedora core packages
>
> hunspell-cs-20060303-5.fc7.i386.rpm
>
> then I converted it to utf8 with iconv
Ok, thanks.
Apparently it's a bug I introduced when I refactored spell.c to use the
readline function for reading and recoding the input file.
I used dictionaries from fedora core packages
hunspell-cs-20060303-5.fc7.i386.rpm
then I converted it to utf8 with iconv
Pavel
2007/9/4, Heikki Linnakangas <[EMAIL PROTECTED]>:
> Pavel Stehule wrote:
> > 2007/9/3, Teodor Sigaev <[EMAIL PROTECTED]>:
> >>> 1. I am not able use fulltext with latin
Pavel Stehule wrote:
> 2007/9/3, Teodor Sigaev <[EMAIL PROTECTED]>:
>>> 1. I am not able use fulltext with latin2 encoding :( I missing note
>>> about only utf8 dictionaries in doc).
>> You can use any server encoding, but dictionary's files should be in utf8 -
>> dictionary will convert utf8 files
2007/9/3, Teodor Sigaev <[EMAIL PROTECTED]>:
> > 1. I am not able use fulltext with latin2 encoding :( I missing note
> > about only utf8 dictionaries in doc).
> You can use any server encoding, but dictionary's files should be in utf8 -
> dictionary will convert utf8 files into server encoding.
>
FAST PostgreSQL wrote:
> In CVS HEAD
>
> workspace=# begin;
> BEGIN
> workspace=# declare cu cursor for select * from t1 for read only;
> DECLARE CURSOR
> workspace=# fetch cu;
> a
> ---
> 1
> (1 row)
>
> workspace=# delete from t1 where current of cu;
> DELETE 1
> workspace=# commit;
> COMMIT
Hi.
I'm confused in the library recommended as a standard by Kerberos
Is the following formal kerberos version good at 3.2.1?
http://web.mit.edu/Kerberos/dist/index.html
Kerberos 3.2.1 for Windows is designed for 32-bit versions of Windows 2000,
XP, 2003, 2003 R2, Vista and WOW64 environmen
61 matches
Mail list logo
