Re: [HACKERS] Parser extensions (maybe for 10?)

> > And the above is called an ad-hominem. > > An "ad hominem" attack means against the person rather than on the > topic of the issue, but I don't think Aleksander did that. I'm not > sure why you think what he wrote was out of line. It reads OK to me. Frankly when I re-read my own e-mails som

Re: [HACKERS] Parser extensions (maybe for 10?)

On Tue, Apr 19, 2016 at 10:05 AM, Andres Freund wrote: > On 2016-04-19 15:32:07 +0300, Aleksander Alekseev wrote: >> > As Tom says, we can't easily break it down into multiple co-operating >> > pieces, so lets forget that as unworkable. >> >> I'm sorry but didn't I just demonstrate the opposite? >

Re: [HACKERS] Parser extensions (maybe for 10?)

2016-04-19 12:49 GMT+02:00 Simon Riggs : > On 12 April 2016 at 06:51, Tom Lane wrote: > >> Craig Ringer writes: >> > The other area where there's room for extension without throwing out the >> > whole thing and rebuilding is handling of new top-level statements. We >> can >> > probably dispatch

Re: [HACKERS] Parser extensions (maybe for 10?)

> On 12 Apr 2016, at 07:36, Arcadiy Ivanov wrote: > > [ > DISTRIBUTE BY { REPLICATION | ROUNDROBIN | { [HASH | MODULO ] ( column_name > ) } } | > DISTRIBUTED { { BY ( column_name ) } | { RANDOMLY } | > DISTSTYLE { EVEN | KEY | ALL } DISTKEY ( column_name ) > ] > [ TO { GROUP groupname | N

Re: [HACKERS] Parser extensions (maybe for 10?)

> On 2016-04-19 12:20:03 +0300, Aleksander Alekseev wrote: > > Can we guarantee that extensions don't conflict? In fact we can > > since we already do it. If all tests pass there is no conflict. > > How does that follow? Even if you were to test all possible extensions > together - obviously not p

Re: [HACKERS] Parser extensions (maybe for 10?)

On 2016-04-19 12:20:03 +0300, Aleksander Alekseev wrote: > Can we guarantee that extensions don't conflict? In fact we can since > we already do it. If all tests pass there is no conflict. How does that follow? Even if you were to test all possible extensions together - obviously not possible - ho

Re: [HACKERS] Parser extensions (maybe for 10?)

On 2016-04-19 15:32:07 +0300, Aleksander Alekseev wrote: > > As Tom says, we can't easily break it down into multiple co-operating > > pieces, so lets forget that as unworkable. > > I'm sorry but didn't I just demonstrate the opposite? I doubt it. > If so it's very > easy to prove - give a count

Re: [HACKERS] Parser extensions (maybe for 10?)

> As Tom says, we can't easily break it down into multiple co-operating > pieces, so lets forget that as unworkable. I'm sorry but didn't I just demonstrate the opposite? If so it's very easy to prove - give a counterexample. As I understand approach I described handles cases named by Tom just fin

Re: [HACKERS] Parser extensions (maybe for 10?)

On Tue, Apr 19, 2016 at 1:49 PM, Simon Riggs wrote: > On 12 April 2016 at 06:51, Tom Lane wrote: > >> Craig Ringer writes: >> > The other area where there's room for extension without throwing out the >> > whole thing and rebuilding is handling of new top-level statements. We >> can >> > probab

Re: [HACKERS] Parser extensions (maybe for 10?)

On 12 April 2016 at 06:51, Tom Lane wrote: > Craig Ringer writes: > > The other area where there's room for extension without throwing out the > > whole thing and rebuilding is handling of new top-level statements. We > can > > probably dispatch the statement text to a sub-parser provided by an

Re: [HACKERS] Parser extensions (maybe for 10?)

> no - it is not possible. Not with Bison parser - it cannot work with > unknown syntax - so isn't possible implement one part by parser A, and > second part by parser B. > > But we can parsers P1 and P2. P1 knows string XX, P2 knows YY. Buildin > parser (BP) knows SQL > > We can have registered

Re: [HACKERS] Parser extensions (maybe for 10?)

2016-04-18 17:44 GMT+02:00 Aleksander Alekseev : > > It depends - can be allowed only one - like plpgsql extensions, or > > can be serialized like pg log extensions > > OK, I understand "can be allowed only one". I doubt it would be a very > useful feature though. > > I'm not sure what do you mean

Re: [HACKERS] Parser extensions (maybe for 10?)

> It depends - can be allowed only one - like plpgsql extensions, or > can be serialized like pg log extensions OK, I understand "can be allowed only one". I doubt it would be a very useful feature though. I'm not sure what do you mean by "serialized like pg log extensions". Lets say extension A

Re: [HACKERS] Parser extensions (maybe for 10?)

2016-04-18 17:25 GMT+02:00 Aleksander Alekseev : > > I cannot to imagine extensible parser based on bison. But the parser > > can be replaced by custom parser. > > > > Some like pgpool or pgbouncer does. The extension can assign own > > parser. Custom parser will be called first, and the integrate

Re: [HACKERS] Parser extensions (maybe for 10?)

> I cannot to imagine extensible parser based on bison. But the parser > can be replaced by custom parser. > > Some like pgpool or pgbouncer does. The extension can assign own > parser. Custom parser will be called first, and the integrated parser > will be used from extension or as fallback. This

Re: [HACKERS] Parser extensions (maybe for 10?)

Hi 2016-04-12 7:10 GMT+02:00 Tom Lane : > Arcadiy Ivanov writes: > > Is there any interest and/or tips to allow a pluggable parser or at > > least allow some syntactical pluggability by extensions? > > There is a fair amount of discussion of this in the archives. The short > answer is that biso

Re: [HACKERS] Parser extensions (maybe for 10?)

On 04/13/2016 04:43 PM, Craig Ringer wrote: On 13 April 2016 at 22:11, José Luis Tallón mailto:jltal...@adv-solutions.net>> wrote: [snip] I can certainly prepare a small patch for the first commitfest of 9.7 if this sounds viable. I'd be surprised if it was popular. I am familiar wi

Re: [HACKERS] Parser extensions (maybe for 10?)

On 13 April 2016 at 22:11, José Luis Tallón wrote: > FWIW, I have previously sketched a "syntax rewriter" of sorts: a simple > filter which is applied to input before the lexer even sees it. > Quite some "syntax magic" can be achieved by allowing an extension to > *hook* into this functionality

Re: [HACKERS] Parser extensions (maybe for 10?)

On 04/12/2016 06:45 AM, Craig Ringer wrote: On 12 April 2016 at 12:36, Arcadiy Ivanov > wrote: Is there any interest and/or tips to allow a pluggable parser or at least allow some syntactical pluggability by extensions? I think this may allow some projects

Re: [HACKERS] Parser extensions (maybe for 10?)

On 12 April 2016 at 13:51, Tom Lane wrote: > Craig Ringer writes: > > The other area where there's room for extension without throwing out the > > whole thing and rebuilding is handling of new top-level statements. We > can > > probably dispatch the statement text to a sub-parser provided by an

Re: [HACKERS] Parser extensions (maybe for 10?)

Craig Ringer writes: > The other area where there's room for extension without throwing out the > whole thing and rebuilding is handling of new top-level statements. We can > probably dispatch the statement text to a sub-parser provided by an > extension that registers interest in that statement n

Re: [HACKERS] Parser extensions (maybe for 10?)

On 12 April 2016 at 13:28, David G. Johnston wrote: > ​As recently discovered there is more than one reason why an intelligent > driver, like the JDBC standard at least requires in a few instances, > requires knowledge of at least some basic structure​ > > ​of the statements it sees before sendi

Re: [HACKERS] Parser extensions (maybe for 10?)

On Mon, Apr 11, 2016 at 9:58 PM, Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote: > *From:* pgsql-hackers-ow...@postgresql.org [mailto: > pgsql-hackers-ow...@postgresql.org] * On Behalf Of *Arcadiy Ivanov > > Currently the parser and lexer are fully fixed at compile-time and not > amen

Re: [HACKERS] Parser extensions (maybe for 10?)

On 12 April 2016 at 13:10, Tom Lane wrote: > > I'm interested in possible solutions to this problem, but it's far > harder than it looks. > > Exactly. Limited extension points where we accept runtime errors and confine the extension points can be OK; e.g. SOME STATEMENT ... WITH (THINGY, OTHER_T

Re: [HACKERS] Parser extensions (maybe for 10?)

Arcadiy Ivanov writes: > Is there any interest and/or tips to allow a pluggable parser or at > least allow some syntactical pluggability by extensions? There is a fair amount of discussion of this in the archives. The short answer is that bison can't do it, and "let's replace bison" is a propos

Re: [HACKERS] Parser extensions (maybe for 10?)

From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Arcadiy Ivanov Currently the parser and lexer are fully fixed at compile-time and not amenable to the extensions - extensions are only capable of introducing functions etc. There is, however, an ad

Re: [HACKERS] Parser extensions (maybe for 10?)

On 12 April 2016 at 12:36, Arcadiy Ivanov wrote: > > Is there any interest and/or tips to allow a pluggable parser or at least > allow some syntactical pluggability by extensions? > I think this may allow some projects to move towards becoming an extension > as opposed to forking the project ent

Re: [HACKERS] Parser emits mysterious error message for very long tokens

Hello, thank you for the opinion. At Fri, 11 Sep 2015 09:31:30 -0400, Tom Lane wrote in <884.1441978...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > Hello, this is a problem on an extreme situation. > > When parser encounters very long tokens, it returns an error > > message which should be m

Re: [HACKERS] Parser emits mysterious error message for very long tokens

Kyotaro HORIGUCHI writes: > Hello, this is a problem on an extreme situation. > When parser encounters very long tokens, it returns an error > message which should be mysterious for users. >> $ perl -e "print \"select '\" . \"x\"x(512*1024*1024) . \"'\"" | psql >> postgres >> ERROR: invalid mem

Re: [HACKERS] Parser Cruft in gram.y

Andres Freund writes: > On 2012-12-20 23:12:55 +, McDevitt, Charles wrote: >>> Another way of attack along these lines might be to use the %glr-parser >>> and then try to cut back on all those redundant rules that were put in >>> to avoid conflicts. The number of key words categories and such

Re: [HACKERS] Parser Cruft in gram.y

> > > > The GLR output from Bison is licensed under the GPL (unlike the LALR > > output). > > So using Bison's GLR mode isn't an option. > > Thats not the case anymore: > http://www.gnu.org/software/bison/manual/html_node/Conditions.html Sorry! My mistake... I didn't realize they changed the ru

Re: [HACKERS] Parser Cruft in gram.y

On 2012-12-20 23:12:55 +, McDevitt, Charles wrote: > > > > Another way of attack along these lines might be to use the %glr-parser > > and then try to cut back on all those redundant rules that were put in > > to avoid conflicts. The number of key words categories and such could > > perhaps a

Re: [HACKERS] Parser Cruft in gram.y

> > Another way of attack along these lines might be to use the %glr-parser > and then try to cut back on all those redundant rules that were put in > to avoid conflicts. The number of key words categories and such could > perhaps also be reduced that way. > > Of course, this is mostly speculati

Re: [HACKERS] Parser Cruft in gram.y

On 2012-12-20 15:58:12 +, Greg Stark wrote: > On Thu, Dec 20, 2012 at 3:18 AM, Tom Lane wrote: > > Greg Stark writes: > >> But I'm not entirely convinced any of this is actually useful. Just > >> becuase the transition table is large doesn't mean it's inefficient. > > > > That's a fair point.

Re: [HACKERS] Parser Cruft in gram.y

On Thu, Dec 20, 2012 at 3:18 AM, Tom Lane wrote: > Greg Stark writes: >> But I'm not entirely convinced any of this is actually useful. Just >> becuase the transition table is large doesn't mean it's inefficient. > > That's a fair point. However, I've often noticed base_yyparse() showing > up ra

Re: [HACKERS] Parser Cruft in gram.y

On 2012-12-20 16:04:49 +0100, Andres Freund wrote: > On 2012-12-20 15:51:37 +0100, Andres Freund wrote: > When doing a source/assembly annotation in SearchCatCache about half of > the misses are attributed to the memcpy() directly at the beginning. Using a separate array for storing the arguments

Re: [HACKERS] Parser Cruft in gram.y

On 2012-12-20 15:51:37 +0100, Andres Freund wrote: > On 2012-12-20 15:45:47 +0100, Andres Freund wrote: > > On 2012-12-20 09:11:46 -0500, Robert Haas wrote: > > > On Thu, Dec 20, 2012 at 8:55 AM, Simon Riggs > > > wrote: > > > > On 18 December 2012 22:10, Robert Haas wrote: > > > >> Well that wo

Re: [HACKERS] Parser Cruft in gram.y

On 2012-12-20 15:45:47 +0100, Andres Freund wrote: > On 2012-12-20 09:11:46 -0500, Robert Haas wrote: > > On Thu, Dec 20, 2012 at 8:55 AM, Simon Riggs wrote: > > > On 18 December 2012 22:10, Robert Haas wrote: > > >> Well that would be nice, but the problem is that I see no way to > > >> implemen

Re: [HACKERS] Parser Cruft in gram.y

On 2012-12-20 09:11:46 -0500, Robert Haas wrote: > On Thu, Dec 20, 2012 at 8:55 AM, Simon Riggs wrote: > > On 18 December 2012 22:10, Robert Haas wrote: > >> Well that would be nice, but the problem is that I see no way to > >> implement it. If, with a unified parser, the parser is 14% of our >

Re: [HACKERS] Parser Cruft in gram.y

On Thu, Dec 20, 2012 at 8:55 AM, Simon Riggs wrote: > On 18 December 2012 22:10, Robert Haas wrote: >> Well that would be nice, but the problem is that I see no way to >> implement it. If, with a unified parser, the parser is 14% of our >> source code, then splitting it in two will probably cran

Re: [HACKERS] Parser Cruft in gram.y

On 18 December 2012 22:10, Robert Haas wrote: > Well that would be nice, but the problem is that I see no way to > implement it. If, with a unified parser, the parser is 14% of our > source code, then splitting it in two will probably crank that number > up well over 20%, because there will be d

Re: [HACKERS] Parser Cruft in gram.y

On 12/18/12 5:10 PM, Robert Haas wrote: > I can't help but suspect that the way we handle keywords today is > monumentally inefficient. The unreserved_keyword products, et al, > just seem somehow badly wrong-headed. We take the trouble to > distinguish all of those cases so that we an turn around

Re: [HACKERS] Parser Cruft in gram.y

On Wed, Dec 19, 2012 at 10:18 PM, Tom Lane wrote: >> valgrind comes with a tool called cachegrind which can emulate the >> cache algorithm on some variants of various cpus and produce reports. >> Can it be made to produce a report for a specific block of memory? > > I believe that oprofile can be

Re: [HACKERS] Parser Cruft in gram.y

Greg Stark writes: > But I'm not entirely convinced any of this is actually useful. Just > becuase the transition table is large doesn't mean it's inefficient. That's a fair point. However, I've often noticed base_yyparse() showing up rather high on profiles --- higher than seemed plausible at t

Re: [HACKERS] Parser Cruft in gram.y

On Tue, Dec 18, 2012 at 10:44 PM, Robert Haas wrote: > Yeah, that's why I don't know how to make it work. It feels like this > is partly artifact of the tool, though. I mean, suppose we haven't > read anything yet. Then, the next token can't be an IDENT, so if we > see an unreserved keyword, we

Re: [HACKERS] Parser Cruft in gram.y

On Tue, Dec 18, 2012 at 10:33:12AM +0100, Dimitri Fontaine wrote: > Robert Haas writes: > > And on the other hand, if you could get a clean split between the two > > grammars, then regardless of exactly what the split was, it might seem > > a win. But it seemed to me when I looked at this that yo

Re: [HACKERS] Parser Cruft in gram.y

On Tue, Dec 18, 2012 at 5:24 PM, Peter Eisentraut wrote: > On 12/18/12 5:10 PM, Robert Haas wrote: >> I can't help but suspect that the way we handle keywords today is >> monumentally inefficient. The unreserved_keyword products, et al, >> just seem somehow badly wrong-headed. We take the troubl

Re: [HACKERS] Parser Cruft in gram.y

On 12/18/12 5:10 PM, Robert Haas wrote: > I can't help but suspect that the way we handle keywords today is > monumentally inefficient. The unreserved_keyword products, et al, > just seem somehow badly wrong-headed. We take the trouble to > distinguish all of those cases so that we an turn around

Re: [HACKERS] Parser Cruft in gram.y

On Tue, Dec 18, 2012 at 4:33 AM, Dimitri Fontaine wrote: > Robert Haas writes: >> And on the other hand, if you could get a clean split between the two >> grammars, then regardless of exactly what the split was, it might seem >> a win. But it seemed to me when I looked at this that you'd have to

Re: [HACKERS] Parser Cruft in gram.y

Robert Haas writes: > And on the other hand, if you could get a clean split between the two > grammars, then regardless of exactly what the split was, it might seem > a win. But it seemed to me when I looked at this that you'd have to > duplicate a lot of stuff and the small parser still wouldn't

Re: [HACKERS] Parser Cruft in gram.y

Robert Haas writes: > I'm frankly kind of shocked at the revelation that the parser is > already 14% of the backend. I knew it was big; I didn't realize it > was THAT big. Yeah, likewise. It makes me wonder whether we aren't past the size of grammar that bison is a good choice for: considering

Re: [HACKERS] Parser Cruft in gram.y

On Sat, Dec 15, 2012 at 11:52 AM, Tom Lane wrote: > "Kevin Grittner" writes: >> Tom Lane wrote: >>> the parser tables are basically number-of-tokens wide by >>> number-of-states high. (In HEAD there are 433 tokens known to the >>> grammar, all but 30 of which are keywords, and 4367 states.) >>> >

Re: [HACKERS] Parser Cruft in gram.y

"Kevin Grittner" writes: > Tom Lane wrote: >> the parser tables are basically number-of-tokens wide by >> number-of-states high. (In HEAD there are 433 tokens known to the >> grammar, all but 30 of which are keywords, and 4367 states.) >> >> Splitting the grammar into multiple grammars is unlikel

Re: [HACKERS] Parser Cruft in gram.y

Tom Lane wrote: > the parser tables are basically number-of-tokens wide by > number-of-states high. (In HEAD there are 433 tokens known to the > grammar, all but 30 of which are keywords, and 4367 states.) > > Splitting the grammar into multiple grammars is unlikely to do > much to improve this -

Re: [HACKERS] Parser Cruft in gram.y

Tom Lane writes: > Let me explain to you why there will never be a situation where we can > consider new keywords to be zero-cost. Thanks for taking the time to do this. > Splitting the grammar into multiple grammars is unlikely to do much to > improve this --- in fact, it could easily make matt

Re: [HACKERS] Parser Cruft in gram.y

Dimitri Fontaine writes: > Now, what about splitting those grammars in order to freely add any new > production rules with or without new keywords for administrative > commands, without a blink of though about the main parser grammar. Let me explain to you why there will never be a situation wher

Re: [HACKERS] Parser - Query Analyser

On 11/18/2012 09:57 PM, Michael Giannakopoulos wrote: > Hi guys, > > Thanks for your answers. Yes, what I meant is to create a function > that takes as an input rows of a specific relation, does something and > returns as an output rows with different attributes. I am > experimenting right now with

Re: [HACKERS] Parser - Query Analyser

On 11/17/2012 10:18 PM, Michael Giannakopoulos wrote: > Hello guys, > > My name is Michail Giannakopoulos and I am a graduate student at > University of Toronto. I have no previous experience in developing a > system like postgreSQL before. > > What I am trying to explore is if it is possible to ex

Re: [HACKERS] Parser - Query Analyser

- Цитат от Michael Giannakopoulos (miccagi...@gmail.com), на 17.11.2012 в 16:18 - > Hello guys, > > My name is Michail Giannakopoulos and I am a graduate student at University > of Toronto. I have no previous experience in developing a system like > postgreSQL before. > > What I am tryi

Re: [HACKERS] Parser - Query Analyser

Michael Giannakopoulos writes: > What I am trying to explore is if it is possible to extend postgreSQL in > order to accept queries of the form: > Select function(att1, att2, att3) AS output(out1, out2, ..., outk) FROM > [database_name]; > where att1, att2, att3 are attributes of the relation [d

Re: [HACKERS] Parser - Query Analyser

On Nov 17, 2012, at 9:18, Michael Giannakopoulos wrote: > Hello guys, > > My name is Michail Giannakopoulos and I am a graduate student at University > of Toronto. I have no previous experience in developing a system like > postgreSQL before. > > What I am trying to explore is if it is possib

Re: [HACKERS] parser handling of large object OIDs

On Wed, Jun 9, 2010 at 10:26 PM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Jun 9, 2010 at 5:02 PM, Robert Haas wrote: >>> I believe that the comment code is probably right, because I think >>> IConst can only handle values < 2^31, whereas OIDs can be as large as >>> 2^32-1. > >> I investi

Re: [HACKERS] parser handling of large object OIDs

Robert Haas writes: > On Wed, Jun 9, 2010 at 5:02 PM, Robert Haas wrote: >> I believe that the comment code is probably right, because I think >> IConst can only handle values < 2^31, whereas OIDs can be as large as >> 2^32-1. > I investigated this a little more and the above analysis turns out

Re: [HACKERS] parser handling of large object OIDs

On Wed, Jun 9, 2010 at 5:02 PM, Robert Haas wrote: > I believe that the comment code is probably right, because I think > IConst can only handle values < 2^31, whereas OIDs can be as large as > 2^32-1. I investigated this a little more and the above analysis turns out to be correct. ALTER LARGE

Re: [HACKERS] Parser - keyword cathegory

Radek Strnad wrote: I'm writing my bachelor thesis and I can't find anywhere what exactly means the third parameter in ScanKeyword in pgsql/src/backend/parser/keywords.c - specificly UNRESERVED_KEYWORD, RESERVED_KEYWORD, TYPE_FUNC_NAME_KEYWORD, COL_NAME_KEYWORD. Could someone explain it to me? Th

Re: [HACKERS] Parser - keyword cathegory

Radek Strnad escreveu: > I'm writing my bachelor thesis and I can't find anywhere what exactly > means the third parameter in ScanKeyword in > pgsql/src/backend/parser/keywords.c - specificly UNRESERVED_KEYWORD, > RESERVED_KEYWORD, TYPE_FUNC_NAME_KEYWORD, COL_NAME_KEYWORD. Could > someone explain

Re: [HACKERS] parser dilemma

Andrew Dunstan írta: Zoltan Boszormenyi wrote: Martijn van Oosterhout írta: On Thu, Apr 19, 2007 at 11:19:40AM +0200, Zoltan Boszormenyi wrote: The problem comes from cases like colname coltype DEFAULT 5! GENERATED ... Since b_expr allows postfix operators, it takes one more token of l

Re: [HACKERS] parser dilemma

Zoltan Boszormenyi wrote: Martijn van Oosterhout írta: On Thu, Apr 19, 2007 at 11:19:40AM +0200, Zoltan Boszormenyi wrote: The problem comes from cases like colname coltype DEFAULT 5! GENERATED ... Since b_expr allows postfix operators, it takes one more token of lookahead than we have

Re: [HACKERS] parser dilemma

Martijn van Oosterhout írta: On Thu, Apr 19, 2007 at 11:19:40AM +0200, Zoltan Boszormenyi wrote: The problem comes from cases like colname coltype DEFAULT 5! GENERATED ... Since b_expr allows postfix operators, it takes one more token of lookahead than we have to tell if the default

Re: [HACKERS] parser dilemma

On Thu, Apr 19, 2007 at 11:19:40AM +0200, Zoltan Boszormenyi wrote: > >The problem comes from cases like > > > > colname coltype DEFAULT 5! GENERATED ... > > > >Since b_expr allows postfix operators, it takes one more token of > >lookahead than we have to tell if the default expression is "5!"

Re: [HACKERS] Parser

[EMAIL PROTECTED] wrote: > I was workin on the parser version 8.1.2 but wheneva simply update > the date the compilation fails not even ne changes. parse error -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- T

Re: [HACKERS] Parser

On Mon, Apr 17, 2006 at 08:07:23AM -0700, [EMAIL PROTECTED] wrote: > Hi > I was workin on the parser version 8.1.2 but wheneva simply update the > date the compilation fails not even ne changes. but the same thing when > done in 8.0.3 it works nicely. What are you talking about? Please provide exa

Re: [HACKERS] Parser bug results in ambiguous errors/behaviour

On Thu, 22 Sep 2005, Tom Lane wrote: > Gavin Sherry <[EMAIL PROTECTED]> writes: > > template1=# update foo set i=2,b='t' and t='bar' where i=1; > > UPDATE 1 > > This is perfectly legal SQL. If it doesn't do what you intended, > well, too bad. We're not going to "fix" it. Hmmm. Okay. It wasn't t

Re: [HACKERS] Parser bug results in ambiguous errors/behaviour

Gavin Sherry <[EMAIL PROTECTED]> writes: > template1=# update foo set i=2,b='t' and t='bar' where i=1; > UPDATE 1 This is perfectly legal SQL. If it doesn't do what you intended, well, too bad. We're not going to "fix" it. regards, tom lane ---(e

Re: [HACKERS] Parser bug results in ambiguous errors/behaviour

Gavin Sherry wrote: A bug/short coming in the parser leads to some pretty ambiguous errors and/or foot shooting. Consider the following: template1=# create table foo(i int, b bool, t text); CREATE TABLE template1=# insert into foo values(1, 'f', 'foo'); INSERT 0 1 template1=# update foo set i=2

Re: [HACKERS] Parser change needed?

Hi Thomas, Please don't get too disheartened that a developer hasn't commented on your stuff yet. Everyone's very busy at the moment. Just hang in there! Chris Thomas Hallgren wrote: Yes, this is another vain attempt to get some attention to the custom config variables patch that I've submi

Re: [HACKERS] Parser Modification Problem: Get the columns of a Table

=?iso-8859-7?q?NK?= <[EMAIL PROTECTED]> writes: > Could you please tell me the way to take the names of the columns? There is no way to do that in the grammar, because it doesn't have the information available. You could probably modify the insert-statement processing in analyze.c to print out th

Re: [HACKERS] Parser translations and schemas

Tom Lane writes: > You write You get > > char(N) pg_catalog.bpchar > pg_catalog.char pg_catalog.char (not bpchar) > real pg_catalog.float4 > myschema.real myschema.real (not float4) >

Re: [HACKERS] Parser abort ignoring following commands

On Sat, May 26, 2001 at 05:57:16PM +0200, Peter Eisentraut wrote: > Tom Lane writes: > > > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > > No, I think there is another problem. How about something without > > > selects: > > > > > $ psql -c 'delete from pk; delete from xx;' > > > ERROR: Relat

Re: [HACKERS] Parser abort ignoring following commands

Peter Eisentraut <[EMAIL PROTECTED]> writes: >> Sure, because the transaction is rolled back. The whole string >> is executed in one transaction. You will definitely break existing >> applications if you change that. > Applications that rely on this behaviour are broken. It was always said > t

Re: [HACKERS] Parser abort ignoring following commands

Peter Eisentraut <[EMAIL PROTECTED]> writes: > No, I think there is another problem. How about something without > selects: > $ psql -c 'delete from pk; delete from xx;' > ERROR: Relation 'xx' does not exist > "pk" exists, but nothing is deleted. Sure, because the transaction is rolled back.

Re: [HACKERS] Parser abort ignoring following commands

Peter Eisentraut <[EMAIL PROTECTED]> writes: > psql -c 'select * from pg_class; select * from no_such_table;' > Shouldn't this at least give me the result of the first select before > aborting the second? The behavior you are complaining of is not the backend's fault. The reason it acts that way