Joe Conway said:
> Marc G. Fournier wrote:
>> On Fri, 2 Jul 2004, Christopher Kings-Lynne wrote:
I am going to bet dollars to donuts that it is your perl version.
Perl 5.00503 is ancient. Try upgrading to at least 5.6.
>>>
>>> Not much I can do about that - it's builtin as part of Fr
1 is not acceptable, and 2 kinda sucks.
Please try adding this to SPI.xs,
#ifndef aTHX_
#define aTHX_
#endif
recompile and test by calling spi_exec_query with more than 2 arguments like
this:
Hmmm, compiled fine, but then I get this:
-bash-2.05b$ createlang -d test plperl
ERROR: could not load li
Steve Holdoway wrote:
Yes, I know it's not possible, but can anyone suggest an alternative for
this problem?
I've written a very simple trigger-driven replication system, which
works in stages. First the trigger generates an entry in a log table
which is a fully formatted sql command... insert
On R, 2004-07-02 at 05:07, Justin Clift wrote:
> Christopher Kings-Lynne wrote:
> >> There is a huge difference between adhering to a standard and limiting
> >> yourself to a standard. The real question is whether PostgreSQL's
> >> goal is to support SQL standards, or whether PostgreSQL's goal is
Christopher Kings-Lynne said:
>
>> 1 is not acceptable, and 2 kinda sucks.
>>
>> Please try adding this to SPI.xs,
>>
>> #ifndef aTHX_
>> #define aTHX_
>> #endif
>>
>> recompile and test by calling spi_exec_query with more than 2
>> arguments like this:
>
> Hmmm, compiled fine, but then I get this:
> > The big picture here is that with the current behavior, it is
possible
> > to keep track of existence of prepared statements without wrapping
or
> > even being aware of transaction activity. This is tremendously
useful
> > for handling them in a generic way because transactions and prepared
>
At 2004-07-02 08:55:56 -0400, [EMAIL PROTECTED] wrote:
>
> In the meantime, does this solve your problem?:
>
> #ifndef eval_pv
> #define eval_pv perl_eval_pv
> #endif
The right way to do this is to #include "ppport.h" from Devel::PPPort.
-- ams
---(end of broadcast)-
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> I am going to bet dollars to donuts that it is your perl version. Perl
>> 5.00503 is ancient. Try upgrading to at least 5.6.
> Not much I can do about that - it's builtin as part of FreeBSD 4.x series.
Chris isn't the only one who's going to
On Fri, 2 Jul 2004, Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
I am going to bet dollars to donuts that it is your perl version. Perl
5.00503 is ancient. Try upgrading to at least 5.6.
Not much I can do about that - it's builtin as part of FreeBSD 4.x series.
Chris isn't t
On Fri, 2004-07-02 at 07:57, Hannu Krosing wrote:
> On R, 2004-07-02 at 05:07, Justin Clift wrote:
> > Christopher Kings-Lynne wrote:
> > >> There is a huge difference between adhering to a standard and limiting
> > >> yourself to a standard. The real question is whether PostgreSQL's
> > >> goal i
Well, if we add them (and they would be very useful I reckon) should we
ensure there's an obvious PG naming thing happening?
Why are they useful If you want PG specific stuff then use the PG
specific catalogs!!!
Chris
---(end of broadcast)---
T
In the meantime, does this solve your problem?:
#ifndef eval_pv
#define eval_pv perl_eval_pv
#endif
Hmmm, I put it in there and rebuilt and reinstalled and tried again:
-bash-2.05b$ createlang -d test plperl
ERROR: could not load library
"/home/chriskl/local/lib/postgresql/plperl.so": dlopen
'/
Larry Rosenman said:
> On Fri, 2 Jul 2004, Tom Lane wrote:
>
>> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
I am going to bet dollars to donuts that it is your perl version.
Perl 5.00503 is ancient. Try upgrading to at least 5.6.
>>
>>> Not much I can do about that - it's builtin
On Fri, Jul 02, 2004 at 12:30:07PM +1200, Oliver Jowett wrote:
> >If it's that important, come up with a generic "session-not-transaction"
> >syntax to temporarily escape bracketing.
>
> Do you have a proposal for this? It seems to me that if your argument is
> that "if you want the old behavio
We seem to have a mixture of old-style and new-style calls which needs to be
cleaned up. I would relly appreciate some experienced eyes being cast over
this, if there are any around.
In the meantime, does this solve your problem?:
I went back to clean CVS and I noticed I had these warnings:
gcc -O2
On Fri, 2 Jul 2004, Larry Rosenman wrote:
On Fri, 2 Jul 2004, Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
I am going to bet dollars to donuts that it is your perl version. Perl
5.00503 is ancient. Try upgrading to at least 5.6.
Not much I can do about that - it's builtin as
On Fri, Jul 02, 2004 at 22:30:05 +0800,
Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> >>Well, if we add them (and they would be very useful I reckon) should we
> >>ensure there's an obvious PG naming thing happening?
>
> Why are they useful If you want PG specific stuff then use the
On Fri, Jul 02, 2004 at 08:51:05AM -0400, Merlin Moncure wrote:
> Right now, I'm transitioning to ExexPrepared to skip the string escaping
> step on the client side. I would hate to lose that ability. ExecParams
> is a little more work to set up (doable, though).
OTOH, if you're taking client
Am Montag, 21. Juni 2004 18:03 schrieb Tom Lane:
> Perhaps we could try to derive a setting from locale charmap, but barf
> and require explicit -E if we can't recognize it?
Considering that we now have a functioning lower/upper, we should try to get
this fixed so users can enjoy the fixed situat
> > Right now, I'm transitioning to ExexPrepared to skip the string
escaping
> > step on the client side. I would hate to lose that ability.
ExecParams
> > is a little more work to set up (doable, though).
>
> OTOH, if you're taking client code queries and replacing them with
> EXECUTEs (which I
Christopher Kings-Lynne said:
>> We seem to have a mixture of old-style and new-style calls which needs
>> to be cleaned up. I would relly appreciate some experienced eyes being
>> cast over this, if there are any around.
>>
>> In the meantime, does this solve your problem?:
>
> I went back to clea
On Fri, Jul 02, 2004 at 11:18:44AM -0400, Merlin Moncure wrote:
> Yes, it would. It would actually make my life a lot easier
> (notwithstanding my minor gripe with ExecParams) because I would no
> longer have to deal with all the complexities surrounding prepared
> statements. This is A Good Th
Tom Lane wrote:
Mike Benoit <[EMAIL PROTECTED]> writes:
On Thu, 2004-07-01 at 18:38 -0400, Alvaro Herrera wrote:
If we change the syntax, say by using SUBCOMMIT/SUBABORT for
subtransactions, then using a simple ABORT would abort the whole
transaction tree.
But then we're back to t
So we have three choices as I see it:
1) revert the change
2) require some minimally recent version of perl
3) fix the issue in place
Preferences?
Joshua/Andrew -- do you want to take a shot at making this work on perl
5.00503?
I personally don't have any desire to make this work on a version of
I'm wondering about the following statement in TransactionIdSetStatus():
*byteptr |= (status << bshift);
When the status is SUBCOMMITTED, the bytemask will have 11 for those two
bytes; therefore, when OR-ing a 10 or 01 mask (committed or aborted),
shouldn't the byte remaing the same as before
> If we change the syntax, say by using SUBCOMMIT/SUBABORT for
> subtransactions, then using a simple ABORT would abort the whole
> transaction tree.
Question: with the new syntax, would issuing a BEGIN inside a already
started transaction result in an error?
My concern is about say, a pl/pgsql f
Joshua D. Drake said:
>
>> So we have three choices as I see it:
>> 1) revert the change
>> 2) require some minimally recent version of perl
>> 3) fix the issue in place
>>
>> Preferences?
>>
>> Joshua/Andrew -- do you want to take a shot at making this work on
>> perl 5.00503?
>
> I personally do
Bruno Wolff III <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
>> Why are they useful If you want PG specific stuff then use the PG
>> specific catalogs!!!
> The information schema could be used to provide a more stable interface.
> The pg catalog changes f
> Right now subtrans.c is not compiling. SlruCtlData is missing the
'locks'
> member in slru.h.
Whoops, I see what happened...never mind (sorry).
Merlin
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
On Fri, Jul 02, 2004 at 01:14:25PM -0400, Merlin Moncure wrote:
> > If we change the syntax, say by using SUBCOMMIT/SUBABORT for
> > subtransactions, then using a simple ABORT would abort the whole
> > transaction tree.
>
> Question: with the new syntax, would issuing a BEGIN inside a already
> st
Right now subtrans.c is not compiling. SlruCtlData is missing the
'locks' member in slru.h.
Merlin
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
On Fri, Jul 02, 2004 at 01:09:56PM -0400, Alvaro Herrera wrote:
Sorry:
> When the status is SUBCOMMITTED, the bytemask will have 11 for those two
should be bitmask
> bytes; therefore, when OR-ing a 10 or 01 mask (committed or aborted),
^ shoul
On Fri, 02 Jul 2004 14:57:18 +0300, Hannu Krosing <[EMAIL PROTECTED]> wrote:
>
> IIRC we were recently told (in this thread) that the SQL standard tells
> to end local customisations with underscore, so it would be
> 'column_comment_'
I didn't write that (or at least, I didn't mean to write that
Alvaro Herrera wrote:
On Fri, Jul 02, 2004 at 01:14:25PM -0400, Merlin Moncure wrote:
If we change the syntax, say by using SUBCOMMIT/SUBABORT for
subtransactions, then using a simple ABORT would abort the whole
transaction tree.
Question: with the new syntax, would issuing a BEGIN inside
Thomas Swan wrote:
Alvaro Herrera wrote:
Yes, I was thinking about this because the current code behaves wrong if
a BEGIN is issued and not inside a transaction block. So we'd need to
do something special in SPI -- not sure exactly what, but the effect
would be that the function can't issue BEGIN
On Fri, Jul 02, 2004 at 01:37:46PM -0500, Thomas Swan wrote:
> Alvaro Herrera wrote:
> >>Then again, since a statement is always transactionally wrapped, would
> >>it be required to always issue SUBBEGIN if issued from within a
> >>function? This would address my concern.
>
> Isn't this counterin
Alvaro Herrera wrote:
On Fri, Jul 02, 2004 at 01:37:46PM -0500, Thomas Swan wrote:
Alvaro Herrera wrote:
Then again, since a statement is always transactionally wrapped, would
it be required to always issue SUBBEGIN if issued from within a
function? This would address my concern.
On R, 2004-07-02 at 20:04, Tom Lane wrote:
> Bruno Wolff III <[EMAIL PROTECTED]> writes:
> > Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> >> Why are they useful If you want PG specific stuff then use the PG
> >> specific catalogs!!!
>
> > The information schema could be used to prov
On Mon, 2004-06-28 at 22:21, Mark Wu wrote:
>
> I'm currently working on a master student research project "support
> triggers on columns" that is supervised by a professor from my
> university (Ottawa U). I have contacted Neil Conway whose name is with
> this item on the TODO list. It happened t
On Fri, Jul 02, 2004 at 03:32:12PM -0500, Thomas Swan wrote:
> Alvaro Herrera wrote:
>
> >Please note that I'm using the term "transaction block" and not
> >"transaction." The distinction is important because everything is
> >always inside a transaction, though it may be an implicit one. A
> >tr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> So again, I'd like to hear any comments about my pattern-matching
> proposal. Is there any problem here that it would not solve?
> Does anyone see a problem in implementing them?
Quoting. Extra parsing work.
Specifically, your proposal (if I
On Fri, Jul 02, 2004 at 05:30:49PM -0400, Alvaro Herrera wrote:
> You can't have subtransactions inside an implicit transaction block, so
Haven't been following this thread closely, but just my 2 cents...
If you collate queries using the semicolon, AFAIK the whole thing is
executed as a single
On Fri, Jul 02, 2004 at 11:51:01PM +0200, Jeroen T. Vermeulen wrote:
> On Fri, Jul 02, 2004 at 05:30:49PM -0400, Alvaro Herrera wrote:
>
> > You can't have subtransactions inside an implicit transaction block, so
>
> Haven't been following this thread closely, but just my 2 cents...
>
> If you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I would like to know your comments on my design and the
> procedure of getting my work accepted.
Glad to see this is being handled by someone. Other things
of the top of my head:
Add support for psql to display the information. Add support
fo
On Fri, Jul 02, 2004 at 09:51:38PM -, Greg Sabino Mullane wrote:
> Specifically, your proposal (if I read it correctly) would require me
> to send in the full SQL statement every time, thus negating a major
Well, like I said, it wouldn't actually _require_ this; it would just
allow transact
Jeroen T. Vermeulen wrote:
Just don't tell me that making
PREPARE respect rollbacks would break compatibility
Why not? It's true.
So many things are true. But _not_ doing so also breaks compatibility,
so like I said, there are counterexamples.
This is nonsense. Not changing the current behaviour
On Sat, Jul 03, 2004 at 11:17:18AM +1200, Oliver Jowett wrote:
> >So many things are true. But _not_ doing so also breaks compatibility,
> >so like I said, there are counterexamples.
>
> This is nonsense. Not changing the current behaviour cannot break
> compatibility, almost by definition.
A
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> You can't have subtransactions inside an implicit transaction block,
It would be folly to design on that assumption. We *will* have that
situation just as soon as plpgsql allows creating subtransactions
(which I trust you'll agree will happen soon). A
Jeroen T. Vermeulen wrote:
On Sat, Jul 03, 2004 at 11:17:18AM +1200, Oliver Jowett wrote:
So many things are true. But _not_ doing so also breaks compatibility,
so like I said, there are counterexamples.
This is nonsense. Not changing the current behaviour cannot break
compatibility, almost by d
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I'm wondering about the following statement in TransactionIdSetStatus():
> *byteptr |= (status << bshift);
> When the status is SUBCOMMITTED, the bytemask will have 11 for those two
> bytes; therefore, when OR-ing a 10 or 01 mask (committed or abort
On Sat, Jul 03, 2004 at 12:16:50PM +1200, Oliver Jowett wrote:
> I stand by my original statement: making no change does not break
> compatibility. Please provide an example of PREPARE/EXECUTE use that
> works under 7.3/7.4 but does not work with current 7.5.
Whether the transaction from "7.3/
At 2004-06-24 13:13:42 -0400, [EMAIL PROTECTED] wrote:
>
> > This is why I proposed originally to keep the non-transactional
> > behavior for Parse messages, but transactional for SQL PREPARE.
> > The latter can be said to be inside the transaction and should
> > behave like so. I think this lower
Jochem van Dieten <[EMAIL PROTECTED]> writes:
> I didn't write that (or at least, I didn't mean to write that :-). The
> SQL standard tells that they will not use trailing underscores,
Um ... actually that's not what it says:
> "NOTE 77 - It is the intention that no specified in ISO/IEC
> 9075 o
Jeroen T. Vermeulen wrote:
On Sat, Jul 03, 2004 at 12:16:50PM +1200, Oliver Jowett wrote:
I stand by my original statement: making no change does not break
compatibility. Please provide an example of PREPARE/EXECUTE use that
works under 7.3/7.4 but does not work with current 7.5.
Whether the
At 2004-07-03 08:20:17 +0530, [EMAIL PROTECTED] wrote:
>
> I would not object to changing PREPARE to be transactional while
> leaving Parse messages alone.
That is to say, it wouldn't cause any problems for me. But since it does
seem to be a nuisance for Oliver and Merlin (among others), I agree w
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> I guess the question then becomes: should we see the frontend-backend
> protocol as a transport layer underneath, and conceptually separate from,
> the SQL session? Or should the protocol be allowed to shine through in
> the way SQL itself is sup
On Fri, Jul 02, 2004 at 07:43:47PM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > You can't have subtransactions inside an implicit transaction block,
>
> It would be folly to design on that assumption. We *will* have that
> situation just as soon as plpgsql allows creati
On Sat, Jul 03, 2004 at 08:20:17AM +0530, Abhijit Menon-Sen wrote:
> At 2004-06-24 13:13:42 -0400, [EMAIL PROTECTED] wrote:
> >
> > > This is why I proposed originally to keep the non-transactional
> > > behavior for Parse messages, but transactional for SQL PREPARE.
> > > The latter can be said to
On Thu, Jul 01, 2004 at 10:19:08AM -0400, Tom Lane wrote:
> AFAICS we can't allow an inner transaction to use a cursor that was
> declared in an outer transaction, because if the inner transaction fails
> then it's not just a matter of the FETCH not rolling back; the
> subtransaction abort will re
59 matches
Mail list logo
