On 29 April 2015 at 21:45, Szymon Guz wrote:
> Hi Devrim,
> I will take a look at this.
>
> regards,
> Szymon
>
> On 29 April 2015 at 18:24, Devrim Gündüz wrote:
>
>>
>> Hi,
>>
>> Anyone? :)
>>
>> Regards, Devrim
>>
>> On Wed, 2015-03-18 at 15:19 +0200, Devrim Gündüz wrote:
>> > Hi,
>> >
>> > Ba
Hi Devrim,
I will take a look at this.
regards,
Szymon
On 29 April 2015 at 18:24, Devrim Gündüz wrote:
>
> Hi,
>
> Anyone? :)
>
> Regards, Devrim
>
> On Wed, 2015-03-18 at 15:19 +0200, Devrim Gündüz wrote:
> > Hi,
> >
> > Background info first: PL/Ruby was originally maintained by Guy Decoux,
>
Hi,
Anyone? :)
Regards, Devrim
On Wed, 2015-03-18 at 15:19 +0200, Devrim Gündüz wrote:
> Hi,
>
> Background info first: PL/Ruby was originally maintained by Guy Decoux,
> who passed away in 2008: https://www.ruby-forum.com/topic/166658 . After
> his death, Akinori MUSHA forked the project and
On Mon, 27 Dec 2004 07:55:27 +0530 (IST), Ameya S. Sakhalkar
<[EMAIL PROTECTED]> wrote:
>
> For my project (main memory DBMS), I have written a main memory filesystem.
> Idea is, the primary copy of data will reside in main memory. (Workable
> only for small size data, at most 2GB).
>
> Now, I wa
Oleg Bartunov kirjutas K, 02.07.2003 kell 11:39:
> > > The problem is recognizing VERSION
> > > (from gram.y)
> > >
> > > version:
> > > INTEGER DOT INTEGER{ $$ = strconcat($1, $3, $2); }
> > > | version DOT INTEGER { $$ = strconcat($1, $3, $2); }
> >
> > removing the line abo
On Wed, 1 Jul 2003, Hannu Krosing wrote:
> Oleg Bartunov kirjutas T, 01.07.2003 kell 15:49:
> > Hi there,
> >
> > attached archive contains simple parser demonstrating our
> > problem. untar it, make, make test
> >
> > Good test:
> > echo -n 12 34.1234 ... | ./parser
> > INTEGER:'12'
> > C
Oleg Bartunov kirjutas T, 01.07.2003 kell 15:49:
> Hi there,
>
> attached archive contains simple parser demonstrating our
> problem. untar it, make, make test
>
> Good test:
> echo -n 12 34.1234 ... | ./parser
> INTEGER:'12'
> CHAR: ' '
> VERSION:'34.1234'
> CHAR: ' '
> DOT:
Sorry,
forgot to attach archive :)
Oleg
On Tue, 1 Jul 2003, Oleg Bartunov wrote:
> Hi there,
>
> attached archive contains simple parser demonstrating our
> problem. untar it, make, make test
>
> Good test:
> echo -n 12 34.1234 ... | ./parser
> INTEGER:'12'
> CHAR: ' '
> VERSIO
On Wed, May 28, 2003 at 12:59:56PM +0200, Sailesh Krishnamurthy wrote:
> elog(NOTICE should send NOTICE messages to the psql client (I think !)
> while elog(LOG while only send it to the logfile you might have
> specified while starting the postmaster
Whether a given elog level is sent to the po
> "Srikanth" == Srikanth M writes:
Srikanth> Dear Sir I am new to postgres and dont know the excat
Srikanth> procedure of testing my code, okay i will use elog, but
Srikanth> please tell me the procedure of testing that.
Srikanth
As you're a big fan of stealing code, why don't
Dear Sir
I am new to postgres and dont know the excat procedure of
testing my code, okay i will use elog, but please tell me the procedure
of testing that.
for example,pls tell what should i do after i add code, what make files
should i run and where should i place the new executables.
I'm guessing his problem is that he's expecting this to come out of psql
and not go to the backend's stdout.
Kris Jurka
On Wed, 28 May 2003, Christopher Kings-Lynne wrote:
> Hi,
>
> This is a much better way than printf:
>
> elog(NOTICE, "this is my test: %s", string);
>
> Chris
>
> - Origi
Hi,
This is a much better way than printf:
elog(NOTICE, "this is my test: %s", string);
Chris
- Original Message -
From: "Srikanth M" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 28, 2003 3:08 PM
Subject: [HACKERS] Help needed in testing my code.
> Dear Sir,
>
>
Why don't you use elog(LOG, instead of printf ?
--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so
Tom Lane dijo:
> Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > I encountered a problem while implementing new CREATE
> > CONVERSION. Since converion procs are dynamically invoked while doing
> > an encoding conversion, it might fail for some reasons:
>
> > (2) buggy conversion proc is defined by
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I encountered a problem while implementing new CREATE
> CONVERSION. Since converion procs are dynamically invoked while doing
> an encoding conversion, it might fail for some reasons:
> (1) stale pg_conversion entry. If someone re-register that proc, the
16 matches
Mail list logo