Re: [HACKERS] automatic parser generation for ecpg
Perl code thats readable and maintainable ;-) In reality - it doesn't look too disimilar from the awk original. I didn't appreciate that we'd probably need to keep 2 versions (one for unix and one for windows). In that case - I'd argue that we only need to "maintain" one and regenerate the other when required. Provided they both work the same, I'd say it doesn't matter what the perl one looked like, because thats not the one that'd be maintained :-) Personally - I'd be tempted to keep this as a background process for the ecpg maintiner anyway rather than a normal end user. Probably using something like a 'syncparser' make target and keep the generation separate from the normal build process. That way - awk/perl (you could then pick just one) would only be a requirement if you want to regenerate the grammer via the 'syncparser' target. This does have the benefit that the ecpg maintainer can then control when the sync'ing is done and that its less likely to inadvertantly break the ecpg branch of source tree. At the end of the day - this is something Michael has just been doing manually already and we're trying to help automate the process.. (ducks for cover) > As against that ... does a2p produce code that is readable/maintainable? > If the code wasn't perl to start with I'd be a little worried about > ending up with ugly hard-to-read code. -- Mike Aubury http://www.aubit.com/ Aubit Computing Ltd is registered in England and Wales, Number: 3112827 Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] automatic parser generation for ecpg
> (Mike, it lacks a copyright notice, I take it BSD is okay). Thats fine with me.. Also - for completeness (for the list) - I think the plan is to convert the awk to perl (via a2p + some tweaking) if awk is not already used as part of the build process (to avoid adding another prerequisite..) -- Mike Aubury http://www.aubit.com/ Aubit Computing Ltd is registered in England and Wales, Number: 3112827 Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] keyword list/ecpg
The same as happens at the moment - nothing... The grammer for the ecpg needs to be re-generated when the grammer in the main parser is changed - whether its a manual or (mostly) automatic task is largely irrelevant. The only downside is that if its not regenerated then the change to gram.y simply wont be reflected in the grammer for ecpg. I personally think its down to the ecpg developers (of which I believe Michael is the main developer) to decide when to do this and to check that its worked. Its just otherwise - there could be a serious case for 'unintended consequences'... Just my 2 pence worth... On Friday 13 June 2008 15:39:48 Alvaro Herrera wrote: > > I personally would stongly favour > > the script being a tool for ecpg tool developers and not used as part of > > a normal installation. > > What happens when a non-Michael developer changes the original gram.y? > Is he expected to run the script before committing too? That sounds > brittle to me. > -- Mike Aubury http://www.aubit.com/ Aubit Computing Ltd is registered in England and Wales, Number: 3112827 Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] keyword list/ecpg
> We're almost certainly going to need some kluges of that sort, so as > long as they're not all over the place I won't object. > > But ... I've seen no evidence that those specific examples are needed. > Why wouldn't we copy all the backend rules? And based on Michael's last > comment it's unclear that we need to avoid adding spaces in the > mechanically generated actions, either (which squares with my gut > feeling about SQL syntax). You'll probably need to get into specific > cases before finding out what kluges you need. I think this was more an 'in principle' - if thats route is ok, then I'll start hacking away properly... I was thinking about the copy on/copy off for more the header info (before the %%) - so we can have a really dumb script that just gets told what blocks to copy - and what to ignore.. There will also be some grammer in the original which we'll need to replace with some ecpg specifics - eg adding grammer for the variables etc. Might be easier to just turn 'off' the original rules and have some custom ecpg stuff appended to the generated code.. Theres also another thing that needs to be decided, which is if the generated ecpg grammer should be developer generated (ie. Michael Meskes runs a script and commits the output), or should be generated for each and every source based installation. I personally would stongly favour the script being a tool for ecpg tool developers and not used as part of a normal installation. -- Mike Aubury http://www.aubit.com/ Aubit Computing Ltd is registered in England and Wales, Number: 3112827 Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] keyword list/ecpg
I took a quick look at this - would it be ok to add some small amounts of 'markup' to the gram.y ? eg : /* ECPGCOPYON */ /* ECPGCOPYOFF */ /* ECPGMODE=NOSPACE */ ... /* ECPGMODE=USESPACE */ etc ? On Friday 13 June 2008 10:47:55 Michael Meskes wrote: > [Sorry, just noticed that I didn't answer this email. ] > > On Wed, Jun 04, 2008 at 05:06:41PM +0100, Mike Aubury wrote: > > It might depend on the tokens.. > > Are ">=", "++" etc single tokens ? > > ... > > > > > Wouldn't it work to just always insert a space between tokens, no > > > matter whether there was one originally? > > There are a few cases where you must not enter a blank, but I'm not sure > whethere these are all in ecpg specific rules anyway. One example that > comes to my mind is the handling of ":" in the connect statement. > > Michael > -- > Michael Meskes > Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) > ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] > Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- Mike Aubury http://www.aubit.com/ Aubit Computing Ltd is registered in England and Wales, Number: 3112827 Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] keyword list/ecpg
It might depend on the tokens.. Are ">=", "++" etc single tokens ? On Wednesday 04 June 2008 17:06:44 Tom Lane wrote: > Mike Aubury <[EMAIL PROTECTED]> writes: > > On Wednesday 04 June 2008 16:11:49 Michael Meskes wrote: > >> There is some small magic to know when to have blanks in between and > >> when not, but that should be doable. > > > > I wouldn't mind having a stab at this if you can expand on the 'magic' > > required. > > Wouldn't it work to just always insert a space between tokens, no matter > whether there was one originally? > > regards, tom lane -- Mike Aubury http://www.aubit.com/ Aubit Computing Ltd is registered in England and Wales, Number: 3112827 Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] keyword list/ecpg
I wouldn't mind having a stab at this if you can expand on the 'magic'
required.
(I'm interested because I might be able to use the same logic to roll a third
version of the .y for Aubit4GL outside of the Postgresql tree)
On Wednesday 04 June 2008 16:11:49 Michael Meskes wrote:
> On Wed, Jun 04, 2008 at 10:21:19AM -0400, Tom Lane wrote:
> > Ugh :-(.
>
> This is why I didn't want to go that route. :-)
>
> > I have not spent much time looking at the ecpg grammar, so feel free to
> > laugh this off, but I had the impression that all the rules derived from
> > the backend grammar have boilerplate action sections (ie, just join the
>
> This is true.
>
> > strings together). So I was hoping that we could leave the backend's
> > .y file more or less as-is, and write a perl script that would go
> > through it and replace each { ... } action with a suitable cat_str call,
> > which it could build on-the-fly by counting the number of rule tokens.
>
> There is some small magic to know when to have blanks in between and
> when not, but that should be doable.
>
> > Then combine that output with the ecpg-specific rules taken from a
> > separate source file. Obviously there would have to be a few small
>
> This might work. Anyone with good perl knowledge interested?
>
> Michael
>
> --
> Michael Meskes
> Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
> ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
> Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
--
Mike Aubury
http://www.aubit.com/
Aubit Computing Ltd is registered in England and Wales, Number: 3112827
Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] ecpg issue - not sending datatype to the backend
This is a little complex to explain - so its probably better with an example..
I don't know if theres some inbuilt function to tell you what datatype a value
is - so 'kludged' this together :
CREATE OR REPLACE FUNCTION rval_type(m date) RETURNS text AS $$
BEGIN
RETURN 'it was a date';
END;
$$ LANGUAGE plpgsql;
CREATE OR REPLACE FUNCTION rval_type(m text) RETURNS text AS $$
BEGIN
RETURN 'it was a text';
END;
$$ LANGUAGE plpgsql;
CREATE OR REPLACE FUNCTION rval_type(m int) RETURNS text AS $$
BEGIN
RETURN 'it was a int';
END;
$$ LANGUAGE plpgsql;
Now - if I have a cpc containing :
main() {
exec sql begin declare section;
date d;
int i;
char a[200];
char lv_out[200];
exec sql end declare section;
exec sql database test1;
d=0;
i=0;
strcpy(a,"-");
memset(lv_out,0,sizeof(lv_out));
exec sql select rval_type(:d) into :lv_out;
if (sqlca.sqlcode<0) sqlprint();
else printf("%s\n",lv_out);
exec sql select rval_type(:i) into :lv_out;
if (sqlca.sqlcode<0) sqlprint();
else printf("%s\n",lv_out);
exec sql select rval_type(:a) into :lv_out;
if (sqlca.sqlcode<0) sqlprint();
else printf("%s\n",lv_out);
}
You can see I'm passing in a date, then an integer, then a character string.
However - when you run the code you get :
it was a text
it was a text
it was a text
This to me looks 'wrong', especially when previous versions of ecpg (<8.0?)
gave the correct :
it was a date
it was a int
it was a text
Any thoughts ?
(This is manifesting itself as arithmetic errors when I'm using dates in my
application)
--
Mike Aubury
Aubit Computing Ltd is registered in England and Wales, Number: 3112827
Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] get rid of psql welcome message
Am I missing something.. $ psql -q testdb testdb=# And - if you're using bash - you could just $ alias "psql=psql -q" $ psql testdb testdb=# On Thursday 17 April 2008 13:39:43 Peter Eisentraut wrote: > Around <http://archives.postgresql.org/pgsql-patches/2008-01/msg00089.php> > it was proposed to truncate the psql welcome screen. What do you think > about that? > > Personally, I'd get rid of it all, because it gets boring after about three > uses, so that we would be at > > [EMAIL PROTECTED]:~$ psql testdb > testdb=# > > The version mismatch warning would remain, of course. > > I'd also like to get rid of the SSL notice but I'm not sure what to replace > it by. Something in the prompt perhaps? > > Btw., any user could put the welcome message in his own psqlrc file via > \echo commands in case they are really attached to it. -- Mike Aubury Aubit Computing Ltd is registered in England and Wales, Number: 3112827 Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Scroll cursor oddity...
Does anyone know what the "correct" behaviour for a scroll cursor should be when you've scrolled past the end ? If you take this SQL for example : create temp table sometab ( a integer); insert into sometab values(1); insert into sometab values(2); insert into sometab values(3); begin work; declare c1 scroll cursor for select * from sometab; fetch next from c1; fetch next from c1; fetch next from c1; fetch next from c1; fetch prior from c1; fetch prior from c1; fetch prior from c1; The first 4 fetches work as expected and return 1,2,3, and the 4th fetch returns no rows as its at the end of the list... ** But ** - when I do the fetch prior, I would have expected it to go back to the '2' row, not the '3' row... ie - under postgresql it appears we've scrolled *past* the last row and need an additional fetch to get back to our last row.. For reference - heres what I get as output : CREATE TABLE INSERT 32429 1 INSERT 32430 1 INSERT 32431 1 BEGIN DECLARE CURSOR a --- 1 (1 row) a --- 2 (1 row) a --- 3 (1 row) a --- (0 rows) a --- 3 (1 row) a --- 2 (1 row) a --- 1 (1 row) TIA -- Mike Aubury Aubit Computing Ltd is registered in England and Wales, Number: 3112827 Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] postgresql.org dns problems
I'm getting the same here... Just went to download 8.3 (if anyone has an alternate mirror...) On Monday 17 March 2008 15:07:58 [EMAIL PROTECTED] wrote: > Hi All, > > Is it me or none of the mirror names can be resolved? > ftp.fr.postgresql.org host unknown > ftp.fr4.postgresql.org host unknown > > > Regards > > -- > Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) > 15, Chemin des Monges+33-5-61-50-97-01 (Fax) > 31190 AUTERIVE +33-6-07-63-80-64 (GSM) > FRANCE Email: [EMAIL PROTECTED] > --- >--- Make your life a dream, make your dream a reality. (St Exupery) -- Mike Aubury Aubit Computing Ltd is registered in England and Wales, Number: 3112827 Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Request for feature - ECPGget_PGconn
Request Overview
Add a function to return the current PGConn used within ecpg..
Background
--
For years now within the Aubit4GL project we've been able to access the PGConn
record used by ecpg by the highly dubious means of accessing an internal
record within ecpg (which has now been removed/hidden).
It would be really useful if we could get at the PGConn connection via a
formal API/function call...
This would be useful to others as it would allow libpq calls on the currently
open connection to use features for which there is no direct ecpg equivilent,
or where the functionality has already been implemented using libpq calls.
(The ability to drop to a lower level of abstraction is common in most db
orientated languages/language extensions like esql/c.)
Implementation
--
This could be implemented by adding the following code to the existing
ecpglib/connect.c file :
PGconn* ECPGget_PGconn(const char *connection_name) {
struct connection * con;
con=ecpg_get_connection(connection_name);
if (con==NULL) return NULL;
return con->connection;
}
TIA
--
Mike Aubury
Aubit Computing Ltd is registered in England and Wales, Number: 3112827
Registered Address : Clayton House,59 Piccadilly,Manchester,M1 2AQ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] CREATE TYPE
OK - i've got the basic input/output working now - but how to I do the extent bit ? eg. allow : create table ( something a4gl_datime(15) ) On Friday 18 July 2003 6:53 pm, [EMAIL PROTECTED] wrote: > Programmers Guide , Chap 10 > http://www.postgresql.org/docs/7.3/static/xtypes.html > > contrib/isbn_issn also provides an implementation example. > > regds > mallah. > > > Can someone point me at some detailed instructions for creating new > > datatypes.. > > > > I've found quite a few web pages that mention it (in passing) and give > > brief examples - but nothing much I can actually work with for my > > purposes.. > > > > Ideally I'd like to use C as the language and the datatype will need an > > 'extent' (like 'char' can be char(10) - although its nothing like a > > char field...) > > > > I'm targetting this at the new 7.4 - so I think i need to use 'version > > 1' method (using Datum etc ?) > > > > Also - the datatype itself is a comlex type which stores half a dozen > > different integers (Its a modified datetime - storing the year, month, > > day, hour, minute, second, but the extent gives it the ability to do > > YEAR TO DAY, HOUR TO SECOND etc, so you only get/set the relevant > > sections). > > When 'selected' it would return a variable length string containing the > > relevant data, and would be set by passing in a string (some of the > > data of which may well be ignored if its outside the extent of the > > column etc) > > > > Hope thats enough - all pointers greatfully received.. > > (and free'd when required :) > > > > > > > > ---(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 > > - > Over 1,00,000 exporters are waiting for your order! Click below to get > in touch with leading Indian exporters listed in the premier > trade directory Exporters Yellow Pages. > http://www.trade-india.com/dyn/gdh/eyp/ > > > > ---(end of broadcast)--- > TIP 8: explain analyze is your friend ---(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
[HACKERS] CREATE TYPE
Can someone point me at some detailed instructions for creating new datatypes.. I've found quite a few web pages that mention it (in passing) and give brief examples - but nothing much I can actually work with for my purposes.. Ideally I'd like to use C as the language and the datatype will need an 'extent' (like 'char' can be char(10) - although its nothing like a char field...) I'm targetting this at the new 7.4 - so I think i need to use 'version 1' method (using Datum etc ?) Also - the datatype itself is a comlex type which stores half a dozen different integers (Its a modified datetime - storing the year, month, day, hour, minute, second, but the extent gives it the ability to do YEAR TO DAY, HOUR TO SECOND etc, so you only get/set the relevant sections). When 'selected' it would return a variable length string containing the relevant data, and would be set by passing in a string (some of the data of which may well be ignored if its outside the extent of the column etc) Hope thats enough - all pointers greatfully received.. (and free'd when required :) ---(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: [HACKERS] ss_family in hba.c
My system has the same problem - struct sockaddr_storage is defined in
/usr/include/bits/socket.h :
struct sockaddr_storage
{
__SOCKADDR_COMMON (__ss_); /* Address family, etc. */
__ss_aligntype __ss_align; /* Force desired alignment. */
char __ss_padding[_SS_PADSIZE];
};
Where SOCKADDR_COMMON is defined in sockaddr.h as :
#define __SOCKADDR_COMMON(sa_prefix) \
sa_family_t sa_prefix##family
That means on my machine it needs __ss_family and not ss_family
Kernel 2.4.18
SuSE 7.1
I changed ss_family to __ss_family and it compiles fine (also in an ip.c &
fe-connect.c IIRC) ...
On Tuesday 17 June 2003 9:49 pm, Kurt Roeckx wrote:
> On Tue, Jun 17, 2003 at 03:32:32PM -0500, Bruno Wolff III wrote:
> > I was looking at this some more and now think there is something wrong
> > with the references to ss_family rather than a missing inlcude file.
> > Perhaps those were supposed to be references to sa_family or there
> > is a missing field from the socket_storage type definition.
>
> The struct sockaddr_storage should only have 1 field you can use
> and that is ss_family. The other fields are there just to get
> the right size and padding.
>
> Does your system have it's own (broken?) struct sockaddr_storage
> maybe?
>
>
> Kurt
>
>
> ---(end of broadcast)---
> TIP 4: Don't 'kill -9' the postmaster
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] SQL parser error
Isn't there a space missing in there ? limit10 - limit 10 All you've done is alias the tablename On Friday 07 March 2003 11:25 am, Teodor Sigaev wrote: > Query > select * from TABLE limit10; > returns all rows, but it seems to me this is a syntax error... > > pgsql 7.3.2 and current CVS has this bug. > > > > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] request for sql3 compliance for the update command
Informix supports 2 different styles for the update - your one would have to be written : UPDATE djp SET(col1, col2) = ((SELECT col1,col2 FROM some_other_table)) Notice the double brackets ! The first signifies a list of values - the second is the brackets around the subquery... (NB If you try to reference the same table in the Update - you'll get an error) For single columns you could still write : UPDATE djp SET col1 = (SELECT col2 FROM some_other_table) Notice - one more set of brackets on the right as on the left > UPDATE djp SET(col1, col2) = (SELECT col2, col1 FROM djp) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] request for sql3 compliance for the update command
On Wednesday 19 February 2003 8:18 pm, Dave Cramer wrote: > I have a customer with a rather large application which uses this > syntax, because they were using informix. There is also a rather > interesting 4GL project called aubit which is on sourceforge. They would > also like to see this supported for the same reasons. Hey - I was going to say that... For the curious: Quick URL - http://aubit4gl.sourceforge.net/ Its a 'clone' of the Informix 4GL tool, a nice 'clean' language specifically designed for writing database applications, with both curses & GTK, support for multiple database types and a bunch of other things... We're about to release version 0.30 - and I was going to wait until then ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
