Re: [PATCHES] [HACKERS] dollar quoting

2004-02-14 Thread Tom Lane
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> ... But how about
>> 42$foo$
>> This is a syntax error in 7.4, and we propose to redefine it as an
>> integer literal '42' followed by a dollar-quote start symbol.

> The test should not succeed anywhere in the string '42$foo$'.

No, it won't.  The problem is that it should, because the backend will
see that as '42' followed by a $foo$ quote start.

> Interacting with lexer states would probably be ... unpleasant. Matching 
> a stream oriented lexer with a line oriented CLI would be messy I suspect.

I think it would not be that bad.  We'd have to run the lexer on the
command input buffer and see what state it terminates in.

regards, tom lane

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [PATCHES] Some new SPI functions

2004-02-14 Thread Tom Lane
"Thomas Hallgren" <[EMAIL PROTECTED]> writes:
> Sure, I'll provide some docs. Just wasn't aware that "patchers" did that.

Who did you think would do it?

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [PATCHES] Some new SPI functions

2004-02-14 Thread Christopher Kings-Lynne


Thomas Hallgren wrote:

Sure, I'll provide some docs. Just wasn't aware that "patchers" did that.

- thomas
Yeah, in PostgreSQL, whoever writes the patch also must submit docs. 
It's the best way of keeping docs up to date :)

Chris

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [PATCHES] support for printing/exporting xml

2004-02-14 Thread Neil Conway
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Your patch has been added to the PostgreSQL unapplied patches list
> at:

In addition to the design problems raised elsewhere, I just wanted to
add that there are as-yet-unaddressed implementation issues with this
patch: I have yet to see a convincing argument for adding an entire
hash table implementation to libpq merely for the sake of this
functionality.

-Neil


---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [PATCHES] Some new SPI functions

2004-02-14 Thread Thomas Hallgren
Sure, I'll provide some docs. Just wasn't aware that "patchers" did that.

- thomas

- Original Message - 
From: "Bruce Momjian" <[EMAIL PROTECTED]>
To: "Thomas Hallgren" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, February 13, 2004 06:12
Subject: Re: [PATCHES] Some new SPI functions


>
> Thomas, if this is ready for application, would you make some SGML
> changes to match, or give me text to add for them.  Thanks.
>
> --
-
>
> Thomas Hallgren wrote:
> > I need three new functions in the Server Programming Interface (SPI)
when
> > mapping an ExecutionPlan to a Java prepared statement (Pl/Java project).
> >
> >
> > The execute method of the prepared statement needs to know if the result
is
> > a ResultSet (SPI_cursor_open) or just a number indicated how many rows
that
> > where affected (SPI_execp). Currently there's no way I can tell by just
> > looking at the plan unless I violate the data hiding and use spi_priv.h.
I
> > really don't want to do that. Hence the need for SPI_is_cursor_plan
> >
> > I send an array of java objects for the arguments. The
> > SPI_cursor_open/SPI_execp of course expects the arguments to be Datum's
and
> > the mapper must convert java objects. The mapping code is based on Oid's
so
> > I need a way to extract the number of expected arguments and the typeid
of
> > each arguments.
> >
> > I find it likely that other pl implementations where similar
support
> > is planned might find these functions useful.
> >
> >
> > Thomas Hallgren
> >
> > Index: src/backend/executor/spi.c
> > ===
> > retrieving revision 1.109
> > diff -u -r1.109 spi.c
> > --- src/backend/executor/spi.c 2 Dec 2003 19:26:47 - 1.109
> > +++ src/backend/executor/spi.c 12 Feb 2004 11:13:11 -
> > @@ -918,6 +918,65 @@
> >   PortalDrop(portal, false);
> >  }
> >
> > +/*
> > + * Returns the Oid representing the type id for argument at argIndex.
First
> > + * parameter is at index zero.
> > + */
> > +Oid
> > +SPI_getargtypeid(void *plan, int argIndex)
> > +{
> > + if (plan == NULL || argIndex < 0 || argIndex >=
((_SPI_plan*)plan)->nargs)
> > + {
> > +  SPI_result = SPI_ERROR_ARGUMENT;
> > +  return InvalidOid;
> > + }
> > + return ((_SPI_plan *) plan)->argtypes[argIndex];
> > +}
> > +
> > +/*
> > + * Returns the number of arguments for the prepared plan.
> > + */
> > +int
> > +SPI_getargcount(void *plan)
> > +{
> > + if (plan == NULL)
> > + {
> > +  SPI_result = SPI_ERROR_ARGUMENT;
> > +  return -1;
> > + }
> > + return ((_SPI_plan *) plan)->nargs;
> > +}
> > +
> > +/*
> > + * Returns true if the plan contains exactly one command
> > + * and that command originates from normal SELECT (i.e.
> > + * *not* a SELECT ... INTO). In essence, the result indicates
> > + * if the command can be used with SPI_cursor_open
> > + *
> > + * Parameters
> > + *plan A plan previously prepared using SPI_prepare
> > + */
> > +bool
> > +SPI_is_cursor_plan(void *plan)
> > +{
> > + List *qtlist;
> > + _SPI_plan *spiplan = (_SPI_plan *) plan;
> > + if (spiplan == NULL)
> > + {
> > +  SPI_result = SPI_ERROR_ARGUMENT;
> > +  return false;
> > + }
> > +
> > + qtlist = spiplan->qtlist;
> > + if(length(spiplan->ptlist) == 1 && length(qtlist) == 1)
> > + {
> > +  Query *queryTree = (Query *) lfirst((List *) lfirst(qtlist));
> > +  if(queryTree->commandType == CMD_SELECT && queryTree->into == NULL)
> > +   return true;
> > + }
> > + return false;
> > +}
> > +
> >  /* === private functions === */
> >
> >  /*
> > Index: src/include/executor/spi.h
> > ===
> > retrieving revision 1.41
> > diff -u -r1.41 spi.h
> > --- src/include/executor/spi.h 2 Dec 2003 19:26:47 - 1.41
> > +++ src/include/executor/spi.h 12 Feb 2004 11:13:21 -
> > @@ -90,6 +90,10 @@
> >  extern void *SPI_saveplan(void *plan);
> >  extern int SPI_freeplan(void *plan);
> >
> > +extern Oid SPI_getargtypeid(void *plan, int argIndex);
> > +extern int SPI_getargcount(void *plan);
> > +extern bool SPI_is_cursor_plan(void *plan);
> > +
> >  extern HeapTuple SPI_copytuple(HeapTuple tuple);
> >  extern TupleDesc SPI_copytupledesc(TupleDesc tupdesc);
> >  extern TupleTableSlot *SPI_copytupleintoslot(HeapTuple tuple,
> >
> >
> >
> > ---(end of broadcast)---
> > TIP 8: explain analyze is your friend
> >
>
> -- 
>   Bruce Momjian|  http://candle.pha.pa.us
>   [EMAIL PROTECTED]   |  (610) 359-1001
>   +  If your life is a hard drive, |  13 Roberts Road
>   +  Christ can be your backup.|  Newtown Square, Pennsylvania
19073
>


---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


[PATCHES] Afrikaans translation of libpq

2004-02-14 Thread Petri Jooste
Hi

I started a new translation of postgresql into Afrikaans (af_ZA).
Attached is the file libpq.po

Please also make sure that Afrikaans is added to the right nls.mk
file.





Mr. JP (Petri) Jooste  
Skool vir Modelleringswetenskappe
School of Modelling Sciences
Vaal Triangle Campus
North-West University / Noordwes-Universiteit / Yunibesiti Ya
Bokone-Bophirima
South Africa

*
Hierdie boodskap (en aanhangsels) is onderhewig aan beperkings en 'n
vrywaringsklousule. Volledige besonderhede beskikbaar by
http://www.puk.ac.za/itb/e-pos/disclaimer.html , of by
[EMAIL PROTECTED]

This message (and attachments) is subject to restrictions and a
disclaimer. Please refer to
http://www.puk.ac.za/itb/e-pos/disclaimer.html for full details, or at
[EMAIL PROTECTED]




libpq.mo
Description: Binary data


libpq.po
Description: Binary data

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faqs/FAQ.html


[PATCHES] Linking references in documentation

2004-02-14 Thread Michael Glaesemann
Below is a patch to provide a few links between the former 
administrator's guide and appropriate reference pages.

Michael Glaesemann
grzm myrealbox com
Index: backup.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/backup.sgml,v
retrieving revision 2.34
diff -c -r2.34 backup.sgml
*** backup.sgml 19 Jan 2004 20:12:30 -  2.34
--- backup.sgml 9 Feb 2004 15:39:06 -
***
*** 260,266 
  pg_dump -Fc dbname > 
filename
  

!  See the pg_dump and pg_restore 
reference pages for details.
  
 

--- 260,266 
  pg_dump -Fc dbname > 
filename
  

!  See the  and 
 reference pages for 
details.
  
 

***
*** 298,305 
 
 
! Please familiarize yourself with the
! pg_dump reference page.
 

   
--- 298,305 
 
 
! Please familiarize yourself with the 
! reference page.
 

   
---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org


[PATCHES] Repost: Linking references in documentation

2004-02-14 Thread Michael Glaesemann
Below is a patch to provide a few links between the former
administrator's guide and appropriate reference pages.
Michael Glaesemann
grzm myrealbox com
Index: backup.sgml
===
RCS file: /projects/cvsroot/pgsql-server/doc/src/sgml/backup.sgml,v
retrieving revision 2.34
diff -c -r2.34 backup.sgml
*** backup.sgml 19 Jan 2004 20:12:30 -  2.34
--- backup.sgml 9 Feb 2004 15:39:06 -
***
*** 260,266 
   pg_dump -Fc dbname >
filename
   
!  See the pg_dump and pg_restore
reference pages for details.
   
  
--- 260,266 
   pg_dump -Fc dbname >
filename
   
!  See the  and
 reference pages for
details.
   
  
***
*** 298,305 
  
  
! Please familiarize yourself with the
! pg_dump reference page.
  
 

--- 298,305 
  
  
! Please familiarize yourself with the 
! reference page.
  
 

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [PATCHES] [HACKERS] dollar quoting

2004-02-14 Thread Andrew Dunstan


Tom Lane wrote:

Andrew Dunstan <[EMAIL PROTECTED]> writes:
 

I ended up not using a regex, which seemed to be a little heavy handed, 
but just writing a small custom recognition function, that should (and I 
think does) mimic the pattern recognition for these tokens used by the 
backend lexer.
   

I looked at this and realized that it still doesn't do very well at
distinguishing $foo$ from other random uses of $.  The problem is that
looking back at just the immediately preceding character isn't enough
context to tell whether a $ is part of an identifier.  Consider the
input
a42$foo$
This is a legal identifier according to PG 7.4.  But how about
42$foo$
This is a syntax error in 7.4, and we propose to redefine it as an
integer literal '42' followed by a dollar-quote start symbol.
The test in the patch I sent is this:

   else if (!dol_quote && valid_dolquote(line+i) &&
(i == 0 ||
 ! ((line[i-prevlen] & 0x80) != 0 ||
isalnum(line[i-prevlen]) ||
line[i-prevlen] == '_' ||
line[i-prevlen] == '$' )))
The test should not succeed anywhere in the string '42$foo$'.

Note that psql does not change any '$foo$' at all - it just passes it to 
the backend. The reason we need this at all in psql is that it has to 
detect the end of a statement, and it has to prompt correctly, and to do 
that it needs to know if we are in a quote (single, double, dollar) or a 
comment.

psql does not detect many syntax errors, or even lexical errors - that 
is the job of the backend - rightly so, I believe.

There's no way to tell these apart with a single-character lookback,
or indeed any fixed number of characters of lookback.
I'm still not convinced, although maybe there's something I'm not getting.

I begin to think that we'll really have to bite the bullet and convert
psql's input parser to use flex.  If we're not scanning with exactly the
same rules as the backend uses, we're going to get the wrong answers.
 

Interacting with lexer states would probably be ... unpleasant. Matching 
a stream oriented lexer with a line oriented CLI would be messy I suspect.

cheers

andrew

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])


Re: [PATCHES] [HACKERS] dollar quoting

2004-02-14 Thread Tom Lane
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I ended up not using a regex, which seemed to be a little heavy handed, 
> but just writing a small custom recognition function, that should (and I 
> think does) mimic the pattern recognition for these tokens used by the 
> backend lexer.

I looked at this and realized that it still doesn't do very well at
distinguishing $foo$ from other random uses of $.  The problem is that
looking back at just the immediately preceding character isn't enough
context to tell whether a $ is part of an identifier.  Consider the
input
a42$foo$
This is a legal identifier according to PG 7.4.  But how about
42$foo$
This is a syntax error in 7.4, and we propose to redefine it as an
integer literal '42' followed by a dollar-quote start symbol.

There's no way to tell these apart with a single-character lookback,
or indeed any fixed number of characters of lookback.

I begin to think that we'll really have to bite the bullet and convert
psql's input parser to use flex.  If we're not scanning with exactly the
same rules as the backend uses, we're going to get the wrong answers.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [PATCHES] TODO : Multiple inserts in a single statement

2004-02-14 Thread Nick Barr
Tom Lane wrote:

Bruce Momjian <[EMAIL PROTECTED]> writes:
 

Nick Barr wrote:
   

Would anyone have any objections if I started to look at the following 
TODO item?

* Allow INSERT INTO tab (col1, ..) VALUES (val1, ..), (val2, ..)
 

 

Sounds good.  Please read the developers FAQ for the suggested process.
   

Also please read the SQL spec.  I recall having looked at this once
with the idea that it should be an easy Sunday-afternoon hack, and
discovering that making it do what the spec envisions was harder than
I thought.  I forget now just what the issues were, but I remember
there's more there than meets the eye.  (Type coercion might have been
part of it ... don't recall for sure ...)
			regards, tom lane

 

Cheers guys. Reading every piece of documentation I can find (isn't 
Google marvellous). Will report back when I have looked at the code a 
bit more.

Nick

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster