Re: [HACKERS] plpgsql - additional extra checks

2017-09-13 1:42 GMT+02:00 Daniel Gustafsson : > > On 08 Apr 2017, at 15:46, David Steele wrote: > > > >> On 1/13/17 6:55 AM, Marko Tiikkaja wrote: > >>> On Fri, Jan 13, 2017 at 2:46 AM, Jim Nasby >>> > wrote: > >>> > >>>On 1/11/17 5:54 AM, Pavel Stehule wrote

Re: [HACKERS] plpgsql - additional extra checks

> On 08 Apr 2017, at 15:46, David Steele wrote: > >> On 1/13/17 6:55 AM, Marko Tiikkaja wrote: >>> On Fri, Jan 13, 2017 at 2:46 AM, Jim Nasby >> > wrote: >>> >>>On 1/11/17 5:54 AM, Pavel Stehule wrote: >>> >>>+too_many_rows >>>+ >>>

Re: [HACKERS] plpgsql, caching, resowners and jit

Andres Freund writes: > After doing so, I got pretty weird crashes. A bit of debugging later it > became apparent that the issue is in how plpgsql caches expression > states: ... > which means we'll re-use ExprStates built in another subtransaction. Sure, why not? They generally aren't going to

[HACKERS] plpgsql, caching, resowners and jit

Hi, While hacking a bit more on my JIT prototype (so I actually know what I'm talking about at pgcon), I encountered an interesting issue. To keep track of the lifetime of JITed functions it seems natural to add support for that to resowners. Not that hard. After doing so, I got pretty weird cr

Re: [HACKERS] plpgsql - additional extra checks

> On 1/13/17 6:55 AM, Marko Tiikkaja wrote: >> On Fri, Jan 13, 2017 at 2:46 AM, Jim Nasby > > wrote: >> >> On 1/11/17 5:54 AM, Pavel Stehule wrote: >> >> +too_many_rows >> + >> + >> + When result is assigned to a

Re: [HACKERS] plpgsql - additional extra checks

On 1/13/17 6:55 AM, Marko Tiikkaja wrote: > On Fri, Jan 13, 2017 at 2:46 AM, Jim Nasby > wrote: > > On 1/11/17 5:54 AM, Pavel Stehule wrote: > > +too_many_rows > + > + > + When result is assigned to a variable

Re: [HACKERS] plpgsql - additional extra checks

On Fri, Jan 13, 2017 at 2:46 AM, Jim Nasby wrote: > On 1/11/17 5:54 AM, Pavel Stehule wrote: > >> +too_many_rows >> + >> + >> + When result is assigned to a variable by INTO >> clause, >> + checks if query returns more than one row. In this case the >> assignment >> +

Re: [HACKERS] plpgsql - additional extra checks

2017-01-13 2:46 GMT+01:00 Jim Nasby : > On 1/11/17 5:54 AM, Pavel Stehule wrote: > >> +too_many_rows >> + >> + >> + When result is assigned to a variable by INTO >> clause, >> + checks if query returns more than one row. In this case the >> assignment >> + is not determ

Re: [HACKERS] plpgsql - additional extra checks

2017-01-13 2:46 GMT+01:00 Jim Nasby : > On 1/11/17 5:54 AM, Pavel Stehule wrote: > >> +too_many_rows >> + >> + >> + When result is assigned to a variable by INTO >> clause, >> + checks if query returns more than one row. In this case the >> assignment >> + is not determ

Re: [HACKERS] plpgsql - additional extra checks

On 1/11/17 5:54 AM, Pavel Stehule wrote: +too_many_rows + + + When result is assigned to a variable by INTO clause, + checks if query returns more than one row. In this case the assignment + is not deterministic usually - and it can be signal some issues in design.

Re: [HACKERS] plpgsql - additional extra checks

2017-01-11 15:08 GMT+01:00 Marko Tiikkaja : > On Wed, Jan 11, 2017 at 2:54 PM, Pavel Stehule > wrote: > >> 1. strict_multi_assignment - checks the number of target variables and >> source values. >> > > I've proposed this before (maybe around a year ago), except the checks > were done at parse ti

Re: [HACKERS] plpgsql - additional extra checks

On Wed, Jan 11, 2017 at 2:54 PM, Pavel Stehule wrote: > 1. strict_multi_assignment - checks the number of target variables and > source values. > I've proposed this before (maybe around a year ago), except the checks were done at parse time, rather than runtime. I much prefer that approach. If

[HACKERS] plpgsql - additional extra checks

Hi I am starting new thread for this patch (related to merging some ideas from plpgsql2 project thread). Here is simple patch with two new extra_warnings, extra_errors checks 1. strict_multi_assignment - checks the number of target variables and source values. 2. too_many_rows - checks if return

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

2016-04-25 19:40 GMT+02:00 Bruce Momjian : > > Good summary. Is there a TODO item here? > no, it is not Regars Pavel > > --- > > On Tue, Mar 15, 2016 at 08:17:07PM -0400, Tom Lane wrote: > > Pavel Stehule writes: > > >>

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Good summary. Is there a TODO item here? --- On Tue, Mar 15, 2016 at 08:17:07PM -0400, Tom Lane wrote: > Pavel Stehule writes: > >> Robert Haas writes: > >>> That's not a dumb idea. I think %TYPE is an Oracle-ism, and it

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Jim Nasby writes: > On 3/3/16 4:51 AM, Pavel Stehule wrote: >> CREATE TABLE a(a int); >> CREATE TABLE b(a a.a%TYPE) >> >> And the people expecting the living relation between table a and table >> b. So when I do ALTER a.a, then b.a should be changed. What if I drop >> a.a or drop a? >> >> So thi

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

2016-03-16 20:53 GMT+01:00 Jim Nasby : > On 3/3/16 4:51 AM, Pavel Stehule wrote: > >> CREATE TABLE a(a int); >> CREATE TABLE b(a a.a%TYPE) >> >> And the people expecting the living relation between table a and table >> b. So when I do ALTER a.a, then b.a should be changed. What if I drop >> a.a or

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On 03/16/2016 09:38 AM, Pavel Stehule wrote: > 2016-03-16 16:50 GMT+01:00 Pavel Stehule >: > 2016-03-16 16:46 GMT+01:00 Joe Conway >: > > On 03/15/2016 05:17 PM, Tom Lane wrote: > > In short, I think we should rej

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

2016-03-16 16:46 GMT+01:00 Joe Conway : > On 03/15/2016 05:17 PM, Tom Lane wrote: > > In short, I think we should reject this implementation and instead try > > to implement the type operators we want in the core grammar's Typename > > production, from which plpgsql will pick it up automatically.

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

2016-03-17 1:02 GMT+01:00 David G. Johnston : > On Wed, Mar 16, 2016 at 4:39 PM, Tom Lane wrote: > >> Jim Nasby writes: >> > On 3/3/16 4:51 AM, Pavel Stehule wrote: >> >> CREATE TABLE a(a int); >> >> CREATE TABLE b(a a.a%TYPE) >> >> >> >> And the people expecting the living relation between tabl

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On Wed, Mar 16, 2016 at 4:39 PM, Tom Lane wrote: > Jim Nasby writes: > > On 3/3/16 4:51 AM, Pavel Stehule wrote: > >> CREATE TABLE a(a int); > >> CREATE TABLE b(a a.a%TYPE) > >> > >> And the people expecting the living relation between table a and table > >> b. So when I do ALTER a.a, then b.a s

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On 3/15/16 7:17 PM, Tom Lane wrote: In short, I think we should reject this implementation and instead try to implement the type operators we want in the core grammar's Typename production, from which plpgsql will pick it up automatically. +1. Something else that's been discussed is allowing [

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On 3/3/16 4:51 AM, Pavel Stehule wrote: CREATE TABLE a(a int); CREATE TABLE b(a a.a%TYPE) And the people expecting the living relation between table a and table b. So when I do ALTER a.a, then b.a should be changed. What if I drop a.a or drop a? So this is reason, why I don't would this feature

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

2016-03-17 0:39 GMT+01:00 Tom Lane : > Jim Nasby writes: > > On 3/3/16 4:51 AM, Pavel Stehule wrote: > >> CREATE TABLE a(a int); > >> CREATE TABLE b(a a.a%TYPE) > >> > >> And the people expecting the living relation between table a and table > >> b. So when I do ALTER a.a, then b.a should be chan

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

2016-03-16 16:50 GMT+01:00 Pavel Stehule : > > > 2016-03-16 16:46 GMT+01:00 Joe Conway : > >> On 03/15/2016 05:17 PM, Tom Lane wrote: >> > In short, I think we should reject this implementation and instead try >> > to implement the type operators we want in the core grammar's Typename >> > product

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On 03/15/2016 05:17 PM, Tom Lane wrote: > In short, I think we should reject this implementation and instead try > to implement the type operators we want in the core grammar's Typename > production, from which plpgsql will pick it up automatically. That is > going to require some other syntax tha

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Pavel Stehule writes: >> Robert Haas writes: >>> That's not a dumb idea. I think %TYPE is an Oracle-ism, and it >>> doesn't seem to have been their best-ever design decision. > Using %TYPE has sense in PostgreSQL too. It's certainly useful functionality; the question is whether this particular

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Pavel Stehule writes: > Where you are expecting the implementation? In PLpgSQL only, or generally > in DDL, or in both levels? I'd envision this as something the main parser does and plpgsql piggybacks on. One of the many half-baked things about %TYPE is that the main parser has an implementatio

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

2016-03-14 20:38 GMT+01:00 Tom Lane : > Robert Haas writes: > > On Mon, Mar 14, 2016 at 12:04 PM, Tom Lane wrote: > >> Or in short: maybe it's time to blow up %TYPE and start fresh. > > > That's not a dumb idea. I think %TYPE is an Oracle-ism, and it > > doesn't seem to have been their best-eve

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Robert Haas writes: > On Mon, Mar 14, 2016 at 12:04 PM, Tom Lane wrote: >> Or in short: maybe it's time to blow up %TYPE and start fresh. > That's not a dumb idea. I think %TYPE is an Oracle-ism, and it > doesn't seem to have been their best-ever design decision. It is, and it wasn't. What co

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On Mon, Mar 14, 2016 at 12:04 PM, Tom Lane wrote: > I wrote: >> However ... one thing I was intending to mention on this thread is that >> "get the array type over this type" isn't the only extension one might >> wish for. Another likely desire is "get the type of field 'foo' of this >> composite

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

I wrote: > However ... one thing I was intending to mention on this thread is that > "get the array type over this type" isn't the only extension one might > wish for. Another likely desire is "get the type of field 'foo' of this > composite type". I don't suggest that this patch needs to impleme

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On 14.03.2016 17:54, Tom Lane wrote: Joe Conway writes: This new version of the patch was posted after the commitfest item was marked ready for committer. Does anyone have further comments or objections to the concept or syntax before I try to take this forward? The quoted excerpt fails to sa

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Joe Conway writes: > This new version of the patch was posted after the commitfest item was > marked ready for committer. Does anyone have further comments or > objections to the concept or syntax before I try to take this forward? The quoted excerpt fails to say what solution was adopted to the

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On 03/03/2016 05:45 AM, Pavel Stehule wrote: > 2016-02-24 22:18 GMT+01:00 Peter Eisentraut >: > > On 1/18/16 4:21 PM, Robert Haas wrote: > > One idea that occurs to me is: If you can DECLARE BAR FOO%TYPE, but > > then you want to make BAR an array of that type

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Hi 2016-03-03 0:27 GMT+01:00 Jim Nasby : > On 3/2/16 3:52 PM, Pavel Stehule wrote: > >> Right, and it's arguably dubious that that doesn't already work. >> Unfortunately, these % things are just random plpgsql parser hacks, >> not >> real types. Maybe this should be done in the main

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Hi 2016-02-24 22:18 GMT+01:00 Peter Eisentraut : > On 1/18/16 4:21 PM, Robert Haas wrote: > > One idea that occurs to me is: If you can DECLARE BAR FOO%TYPE, but > > then you want to make BAR an array of that type rather than a scalar, > > why not write that as DECLARE BAR FOO%TYPE[]? That seems

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On 3/2/16 3:52 PM, Pavel Stehule wrote: Right, and it's arguably dubious that that doesn't already work. Unfortunately, these % things are just random plpgsql parser hacks, not real types. Maybe this should be done in the main PostgreSQL parser with parameter hooks, if we wanted

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Hi 2016-02-24 22:18 GMT+01:00 Peter Eisentraut : > On 1/18/16 4:21 PM, Robert Haas wrote: > > One idea that occurs to me is: If you can DECLARE BAR FOO%TYPE, but > > then you want to make BAR an array of that type rather than a scalar, > > why not write that as DECLARE BAR FOO%TYPE[]? That seems

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On 1/18/16 4:21 PM, Robert Haas wrote: > One idea that occurs to me is: If you can DECLARE BAR FOO%TYPE, but > then you want to make BAR an array of that type rather than a scalar, > why not write that as DECLARE BAR FOO%TYPE[]? That seems quite > natural to me. Right, and it's arguably dubious t

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Hi 2016-02-24 10:48 GMT+01:00 Artur Zakirov : On 21.02.2016 11:31, Pavel Stehule wrote: > >> Hi >> >> I am sending updated version - the changes are related to fix comments. >> >> > Great. > > I am new in reviewing, I think Pavel took into account all comments. This > patch is compiled and regres

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On 21.02.2016 11:31, Pavel Stehule wrote: Hi I am sending updated version - the changes are related to fix comments. Great. I am new in reviewing, I think Pavel took into account all comments. This patch is compiled and regression tests are passed. So I change its status to "Ready for Comm

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Hi I am sending updated version - the changes are related to fix comments. 2016-02-19 10:41 GMT+01:00 Artur Zakirov : > It seems all fixes are done. I tested the patch and regression tests > passed. > > I think here Alvaro means that you should keep original comment without > the ROW. Like this:

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

It seems all fixes are done. I tested the patch and regression tests passed. On 27.01.2016 20:58, Pavel Stehule wrote: > --- 1681,1687 >* -- >*/ > PLpgSQL_type * > ! plpgsql_parse_wordtype(char *ident, int reftype_mode) > { > PL

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Hi 2016-01-18 21:37 GMT+01:00 Alvaro Herrera : > > diff --git a/src/pl/plpgsql/src/pl_comp.c b/src/pl/plpgsql/src/pl_comp.c > > new file mode 100644 > > index 1ae4bb7..c819517 > > *** a/src/pl/plpgsql/src/pl_comp.c > > --- b/src/pl/plpgsql/src/pl_comp.c > > *** plpgsql_parse_tripword(

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

2016-01-20 0:34 GMT+01:00 Robert Haas : > On Tue, Jan 19, 2016 at 4:53 AM, Pavel Stehule > wrote: > > It is, but sometime the polymorphic types can help. > > > > The proposed feature/syntax has sense primary for polymorphic types. It > > should to follow our polymorphic types. The primary pair is

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On Tue, Jan 19, 2016 at 4:53 AM, Pavel Stehule wrote: > It is, but sometime the polymorphic types can help. > > The proposed feature/syntax has sense primary for polymorphic types. It > should to follow our polymorphic types. The primary pair is > "anyarray","anyelement" -> "arraytype","elemement

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

2016-01-18 22:48 GMT+01:00 Robert Haas : > On Mon, Jan 18, 2016 at 4:35 PM, Pavel Stehule > wrote: > >> I know that Oracle uses syntax of this general type, but I've always > >> found it ugly. It's also pretty non-extensible. You could want > >> similar things for range types and any other cont

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On Mon, Jan 18, 2016 at 4:35 PM, Pavel Stehule wrote: >> I know that Oracle uses syntax of this general type, but I've always >> found it ugly. It's also pretty non-extensible. You could want >> similar things for range types and any other container types we might >> get in the future, but clear

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

2016-01-18 22:21 GMT+01:00 Robert Haas : > On Mon, Jan 18, 2016 at 3:51 PM, Alvaro Herrera > wrote: > > BTW are we all agreed that enabling > > foo%ARRAYTYPE > > and > > foo%ELEMENTYPE > > in plpgsql's DECLARE section is what we want for this? > > I know that Oracle uses syntax of this genera

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On Mon, Jan 18, 2016 at 3:51 PM, Alvaro Herrera wrote: > BTW are we all agreed that enabling > foo%ARRAYTYPE > and > foo%ELEMENTYPE > in plpgsql's DECLARE section is what we want for this? I know that Oracle uses syntax of this general type, but I've always found it ugly. It's also pretty no

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

FWIW the reason I read through this patch is that I wondered if there was anything in common with this other patch https://commitfest.postgresql.org/8/459/ -- and the answer seems to be "no". What that patch does is add a new construct TYPE(1+1) which in this case returns "int4"; I guess if we

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

> diff --git a/src/pl/plpgsql/src/pl_comp.c b/src/pl/plpgsql/src/pl_comp.c > new file mode 100644 > index 1ae4bb7..c819517 > *** a/src/pl/plpgsql/src/pl_comp.c > --- b/src/pl/plpgsql/src/pl_comp.c > *** plpgsql_parse_tripword(char *word1, char > *** 1617,1622 > --- 1617,1677 >

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On Tue, Dec 22, 2015 at 5:59 PM, Pavel Stehule wrote: > Hi > > 2015-12-21 16:21 GMT+01:00 Artur Zakirov : >> >> Hi. >> I have tried to do some review of this patch. Below are my comments. >> >> Introduction: >> >> This patch fixes and adds the following functionality: >> - %TYPE - now can be used

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Hi 2015-12-21 16:21 GMT+01:00 Artur Zakirov : > Hi. > I have tried to do some review of this patch. Below are my comments. > > Introduction: > > This patch fixes and adds the following functionality: > - %TYPE - now can be used for composite types. > - %ARRAYTYPE - new functionality, provides the

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Hi 2015-12-21 16:21 GMT+01:00 Artur Zakirov : > Hi. > I have tried to do some review of this patch. Below are my comments. > > Introduction: > > This patch fixes and adds the following functionality: > - %TYPE - now can be used for composite types. > - %ARRAYTYPE - new functionality, provides t

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Hi. I have tried to do some review of this patch. Below are my comments. Introduction: This patch fixes and adds the following functionality: - %TYPE - now can be used for composite types. - %ARRAYTYPE - new functionality, provides the array type from a variable or table column. - %ELEMENTTYPE

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

2015-12-21 1:06 GMT+01:00 Jim Nasby : > On 10/30/15 6:01 AM, Pavel Stehule wrote: > >> I am sending patch that enables to use references to polymorphic >> parameters of row types. Another functionality is possibility to get >> array or element type of referenced variable. It removes some gaps when

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

On 10/30/15 6:01 AM, Pavel Stehule wrote: I am sending patch that enables to use references to polymorphic parameters of row types. Another functionality is possibility to get array or element type of referenced variable. It removes some gaps when polymorphic parameters are used. Did this make

Re: [HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

2015-10-19 9:52 GMT+02:00 Pavel Stehule : > Hi, > > We cannot to declare variable with referenced type on other composite > variable. This limit is probably artificial, because any composite type is > any type too in PostgreSQL. > > The issue: > > referencing on composite variables doesn't work >

[HACKERS] plpgsql - DECLARE - cannot to use %TYPE or %ROWTYPE for composite types

Hi, We cannot to declare variable with referenced type on other composite variable. This limit is probably artificial, because any composite type is any type too in PostgreSQL. The issue: referencing on composite variables doesn't work do $$ declare x int; y x%type; begin end; $$; -- ok do $$ d

Re: [HACKERS] plpgsql versus domains

2015-03-03 20:32 GMT+01:00 Tom Lane : > I wrote: > > Robert Haas writes: > >> On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane wrote: > >>> To some extent this is a workaround for the fact that plpgsql does type > >>> conversions the way it does (ie, by I/O rather than by using the > parser's > >>> cas

Re: [HACKERS] plpgsql versus domains

I wrote: > Robert Haas writes: >> On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane wrote: >>> To some extent this is a workaround for the fact that plpgsql does type >>> conversions the way it does (ie, by I/O rather than by using the parser's >>> cast mechanisms). We've talked about changing that, but

Re: [HACKERS] plpgsql versus domains

On 2/28/15 11:26 PM, Tom Lane wrote: Also, instrumenting the code showed that TypeCacheConstrCallback gets called quite a lot during the standard regression tests, which is why I went out of my way to make it quick. Almost all of those cache flushes are from non-domain-related updates on pg_type

Re: [HACKERS] plpgsql versus domains

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> This is the first attempt at weaponizing the memory context > Tom> reset/delete feature, and I'm fairly happy with it, except for one > Tom> thing: I had to #include utils/memnodes.h into typcache.h in order > Tom> to preserve the inten

Re: [HACKERS] plpgsql versus domains

> "Tom" == Tom Lane writes: Tom> This is the first attempt at weaponizing the memory context Tom> reset/delete feature, and I'm fairly happy with it, except for one Tom> thing: I had to #include utils/memnodes.h into typcache.h in order Tom> to preserve the intended property that the call

Re: [HACKERS] plpgsql versus domains

Andres Freund writes: > On 2015-02-26 13:53:18 -0500, Tom Lane wrote: >> Andres Freund writes: >>> You're probably going to kill me because of the increased complexity, >>> but how about making typecache.c smarter, more in the vein of >>> relcache.c, and store the relevant info in there? >> I th

Re: [HACKERS] plpgsql versus domains

2015-02-27 21:57 GMT+01:00 Tom Lane : > Robert Haas writes: > > On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane wrote: > >> To some extent this is a workaround for the fact that plpgsql does type > >> conversions the way it does (ie, by I/O rather than by using the > parser's > >> cast mechanisms). W

Re: [HACKERS] plpgsql versus domains

Robert Haas writes: > On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane wrote: >> To some extent this is a workaround for the fact that plpgsql does type >> conversions the way it does (ie, by I/O rather than by using the parser's >> cast mechanisms). We've talked about changing that, but people seem to

Re: [HACKERS] plpgsql versus domains

On Thu, Feb 26, 2015 at 1:53 PM, Tom Lane wrote: > To some extent this is a workaround for the fact that plpgsql does type > conversions the way it does (ie, by I/O rather than by using the parser's > cast mechanisms). We've talked about changing that, but people seem to > be afraid of the compat

Re: [HACKERS] plpgsql versus domains

Andres Freund writes: > On 2015-02-26 13:53:18 -0500, Tom Lane wrote: >> I thought that's what I was proposing in point #1. > Sure, but my second point was to avoid duplicating that information into > ->fcinfo and such and instead reference the typecache entry from > there. So that if the typecac

Re: [HACKERS] plpgsql versus domains

2015-02-26 19:53 GMT+01:00 Tom Lane : > Andres Freund writes: > > On 2015-02-26 12:31:46 -0500, Tom Lane wrote: > >> 2. In plpgsql, explicitly model a domain type as being its base type > >> plus some constraints --- that is, stop depending on domain_in() to > >> enforce the constraints, and do i

Re: [HACKERS] plpgsql versus domains

On 2015-02-26 13:53:18 -0500, Tom Lane wrote: > Andres Freund writes: > > Hm. A bit sad to open code that in plpgsql instead of making it > > available more generally. > > The actual checking wouldn't be open-coded, it would come from > domain_check() (or possibly a modified version of that). It

Re: [HACKERS] plpgsql versus domains

Andres Freund writes: > On 2015-02-26 12:31:46 -0500, Tom Lane wrote: >> 2. In plpgsql, explicitly model a domain type as being its base type >> plus some constraints --- that is, stop depending on domain_in() to >> enforce the constraints, and do it ourselves. This would mean that >> the FmgrInf

Re: [HACKERS] plpgsql versus domains

Hi, On 2015-02-26 12:31:46 -0500, Tom Lane wrote: > It's really slow, because any assignment to a domain variable goes through > the slow double-I/O-conversion path in exec_cast_value, even if no actual > work is needed. Hm, that's surely not nice for some types. Doing syscache lookups every time

Re: [HACKERS] plpgsql versus domains

Hi 2015-02-26 18:31 GMT+01:00 Tom Lane : > At the behest of Salesforce, I've been looking into improving plpgsql's > handling of variables of domain types, which is currently pretty awful. > It's really slow, because any assignment to a domain variable goes through > the slow double-I/O-conversio

[HACKERS] plpgsql versus domains

At the behest of Salesforce, I've been looking into improving plpgsql's handling of variables of domain types, which is currently pretty awful. It's really slow, because any assignment to a domain variable goes through the slow double-I/O-conversion path in exec_cast_value, even if no actual work i

Re: [HACKERS] plpgsql plan changes causing failure after repeated invocation

Merlin Moncure wrote: > I chased down a problem today where users were reporting sporadic > failures in the application. Turns out, the function would work > exactly 5 times and then fail; this is on 9.2. I think I understand > why this is happening and I'm skeptical it's a bug in postgres, but

[HACKERS] plpgsql plan changes causing failure after repeated invocation

I chased down a problem today where users were reporting sporadic failures in the application. Turns out, the function would work exactly 5 times and then fail; this is on 9.2. I think I understand why this is happening and I'm skeptical it's a bug in postgres, but I thought I'd socialize it. W

Re: [HACKERS] plpgsql defensive mode

2014-09-06 19:54 GMT+02:00 Marko Tiikkaja : > On 2014-09-06 7:50 PM, Pavel Stehule wrote: > >> 2014-09-06 16:31 GMT+02:00 Marko Tiikkaja : >> >>> How do you run queries which affect more than one row in this mode? >>> Because that's crucial as well. We want something we can run 100% of our >>> co

Re: [HACKERS] plpgsql defensive mode

On 2014-09-06 7:50 PM, Pavel Stehule wrote: 2014-09-06 16:31 GMT+02:00 Marko Tiikkaja : How do you run queries which affect more than one row in this mode? Because that's crucial as well. We want something we can run 100% of our code on, but with a slightly more convenient syntax than PL/PgSQL

Re: [HACKERS] plpgsql defensive mode

2014-09-06 16:31 GMT+02:00 Marko Tiikkaja : > On 2014-09-06 7:51 AM, Pavel Stehule wrote: > >> In this mode .. all DML statements should to return EXACTLY ONE row with >> exception CURSORs and FOR LOOP cycle where more rows is expected. But in >> this case we can raise a exception NODATA if there

Re: [HACKERS] plpgsql defensive mode

On 2014-09-06 4:41 PM, Joel Jacobson wrote: On 6 sep 2014, at 16:32, Marko Tiikkaja wrote: How do you run queries which affect more than one row in this mode? Because that's crucial as well. We want something we can run 100% of our code on, but with a slightly more convenient syntax than PL/

Re: [HACKERS] plpgsql defensive mode

> On 6 sep 2014, at 16:32, Marko Tiikkaja wrote: > > How do you run queries which affect more than one row in this mode? Because > that's crucial as well. We want something we can run 100% of our code on, > but with a slightly more convenient syntax than PL/PgSQL provides right when > coding d

Re: [HACKERS] plpgsql defensive mode

On 2014-09-06 7:51 AM, Pavel Stehule wrote: In this mode .. all DML statements should to return EXACTLY ONE row with exception CURSORs and FOR LOOP cycle where more rows is expected. But in this case we can raise a exception NODATA if there is no row. In this mode late IO casting will be disable

Re: [HACKERS] plpgsql defensive mode

On Sat, Sep 6, 2014 at 7:51 AM, Pavel Stehule wrote: > Hi > > There was a long discussion about future of PLpgSQL. > > I accept so Joel, Marko has good ideas based on probably strong experience > from their domain. I can't accept their implementation and proposals as > default for PLpgSQL now and

[HACKERS] plpgsql defensive mode

Hi There was a long discussion about future of PLpgSQL. I accept so Joel, Marko has good ideas based on probably strong experience from their domain. I can't accept their implementation and proposals as default for PLpgSQL now and in future. They try to mix wine and vodka concepts, and it has no

Re: [HACKERS] plpgsql redesign (related to plpgsql check function)

2013/5/28 Heikki Linnakangas : > On 28.05.2013 11:00, Pavel Stehule wrote: >> >> Hello all >> >> I am searching way how to push our plpgsql_check_function to upstream. >> One possibility is redesign of plpgsql architecture. >> >> Now, we have two stages -> compilation and execution, and almost all

Re: [HACKERS] plpgsql redesign (related to plpgsql check function)

On 28.05.2013 11:00, Pavel Stehule wrote: Hello all I am searching way how to push our plpgsql_check_function to upstream. One possibility is redesign of plpgsql architecture. Now, we have two stages -> compilation and execution, and almost all compilation logic is in gram file. If I understan

[HACKERS] plpgsql redesign (related to plpgsql check function)

Hello all I am searching way how to push our plpgsql_check_function to upstream. One possibility is redesign of plpgsql architecture. Now, we have two stages -> compilation and execution, and almost all compilation logic is in gram file. If I understand to this design well, then a reason for it i

Re: [HACKERS] plpgsql versus SPI plan abstraction

On 30/01/13 22:23, Tom Lane wrote: BTW, I'm also wondering if it's really necessary for plpython/plpy_spi.c to be looking into spi_priv.h ... As far as I can tell, it's not necessary, spi.h would be perfectly fine. Cheers, Jan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.

Re: [HACKERS] plpgsql versus SPI plan abstraction

2013/1/30 Tom Lane : > I looked into the odd behavior noted recently on pgsql-novice that > the error context stack reported by plpgsql could differ between > first and subsequent occurrences of the same error: > http://www.postgresql.org/message-id/26370.1358539...@sss.pgh.pa.us > > This seems to

[HACKERS] plpgsql versus SPI plan abstraction

I looked into the odd behavior noted recently on pgsql-novice that the error context stack reported by plpgsql could differ between first and subsequent occurrences of the same error: http://www.postgresql.org/message-id/26370.1358539...@sss.pgh.pa.us This seems to be specific to errors that are d

Re: [HACKERS] plpgsql gram.y make rule

On Mon, Sep 24, 2012 at 10:21 PM, Tom Lane wrote: > Peter Eisentraut writes: >> I wanted to refactor the highly redundant flex and bison rules >> throughout the source into common pattern rules. (Besides saving some >> redundant code, this could also help some occasionally flaky code in >> pgxs

Re: [HACKERS] plpgsql gram.y make rule

Peter Eisentraut writes: > I wanted to refactor the highly redundant flex and bison rules > throughout the source into common pattern rules. (Besides saving some > redundant code, this could also help some occasionally flaky code in > pgxs modules.) The only outlier that breaks this is in plpgsq

[HACKERS] plpgsql gram.y make rule

I wanted to refactor the highly redundant flex and bison rules throughout the source into common pattern rules. (Besides saving some redundant code, this could also help some occasionally flaky code in pgxs modules.) The only outlier that breaks this is in plpgsql pl_gram.c: gram.y I would like

Re: [HACKERS] plpgsql leaking memory when stringifying datums

I wrote: > BTW, it occurs to me to wonder whether we need to worry about such > subsidiary leaks in type input functions as well. Sure enough, once you find an input function that leaks memory, there's trouble: create type myrow as (f1 text, f2 text, f3 text); create or replace function leak_ass

Re: [HACKERS] plpgsql leaking memory when stringifying datums

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes: > While chasing a PL/Python memory leak, I did a few tests with PL/pgSQL > and I think there are places where memory is not freed sufficiently early. I think the basic issue here is that the type output function might generate (and not bother to free) addi

[HACKERS] plpgsql leaking memory when stringifying datums

While chasing a PL/Python memory leak, I did a few tests with PL/pgSQL and I think there are places where memory is not freed sufficiently early. Attached are two functions that when run will make the backend's memory consumption increase until they finish. With both, the cause is convert_value_to

Re: [HACKERS] plpgsql versus long ELSIF chains

On 27.10.2011 19:18, Tom Lane wrote: So really what needs to be done here is to make ELSIF chains explicit in the parsetree representation, and handle them via looping not recursion at runtime. This will also make it a lot easier to do the grammar via left-recursion. So I'm going to go off and

  1   2   3   4   5   >