On 08/07/2014 01:11 AM, Marko Tiikkaja wrote:
On 7/21/14, 10:56 PM, I wrote:
Here's a patch which allows you to notice those annoying bugs with INTO
slightly more quickly. Adding to the next commit phest.
New version, fixed bugs with set operations and VALUES lists.
Looks good.
It seems
On 8/21/14, 1:19 PM, Heikki Linnakangas wrote:
On 08/07/2014 01:11 AM, Marko Tiikkaja wrote:
On 7/21/14, 10:56 PM, I wrote:
Here's a patch which allows you to notice those annoying bugs with INTO
slightly more quickly. Adding to the next commit phest.
New version, fixed bugs with set
On 08/21/2014 02:09 PM, Marko Tiikkaja wrote:
On 8/21/14, 1:19 PM, Heikki Linnakangas wrote:
On 08/07/2014 01:11 AM, Marko Tiikkaja wrote:
On 7/21/14, 10:56 PM, I wrote:
Here's a patch which allows you to notice those annoying bugs with INTO
slightly more quickly. Adding to the next commit
On 7/21/14, 10:56 PM, I wrote:
Here's a patch which allows you to notice those annoying bugs with INTO
slightly more quickly. Adding to the next commit phest.
New version, fixed bugs with set operations and VALUES lists.
.marko
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
On 7/22/14, 7:06 AM, Pavel Stehule wrote:
I looked on this patch and I am thinking so it is not a good idea. It
introduce early dependency between functions and pg_class based objects.
What dependency? The patch only looks at the raw parser output, so it
won't e.g. know whether SELECT *
2014-07-22 8:52 GMT+02:00 Marko Tiikkaja ma...@joh.to:
On 7/22/14, 7:06 AM, Pavel Stehule wrote:
I looked on this patch and I am thinking so it is not a good idea. It
introduce early dependency between functions and pg_class based objects.
What dependency? The patch only looks at the raw
Hi
I looked on this patch and I am thinking so it is not a good idea. It
introduce early dependency between functions and pg_class based objects.
This check should not be integrated to function validation directly.
We can integrate it to plpgsql_check
Regards
Pavel
2014-07-21 22:56