2011/7/22 Jim Nasby :
> On Jul 19, 2011, at 10:51 PM, Pavel Stehule wrote:
>>> If you mean that such checks would be done automatically, no, they
>>> shouldn't be. Consider a function that creates a table and then uses
>>> it, or even just depends on using a table that doesn't yet exist when
>>> y
On Jul 19, 2011, at 10:51 PM, Pavel Stehule wrote:
>> If you mean that such checks would be done automatically, no, they
>> shouldn't be. Consider a function that creates a table and then uses
>> it, or even just depends on using a table that doesn't yet exist when
>> you do CREATE FUNCTION.
>
>
On 07/20/2011 05:24 AM, Tom Lane wrote:
=?ISO-8859-1?Q?Petr_Jel=EDnek?= writes:
But, I think we should add valitation hook to plpgsql plugin structure
so that you don't have to actually execute the function to check it -
curretly there are only executing hooks which is why the plugin only
works
2011/7/20 Tom Lane :
> =?ISO-8859-1?Q?Petr_Jel=EDnek?= writes:
>> But, I think we should add valitation hook to plpgsql plugin structure
>> so that you don't have to actually execute the function to check it -
>> curretly there are only executing hooks which is why the plugin only
>> works when yo
Dne 19. července 2011 21:15 Petr Jelínek napsal(a):
> On 07/17/2011 10:31 PM, Jim Nasby wrote:
>>
>> On Jul 7, 2011, at 11:31 PM, Pavel Stehule wrote:
>>>
>>> a lazy deep SQL validation inside plpgsq functions is interesting
>>> attribute. It allows to work with temporary tables and it make testin
On 07/17/2011 10:31 PM, Jim Nasby wrote:
On Jul 7, 2011, at 11:31 PM, Pavel Stehule wrote:
a lazy deep SQL validation inside plpgsq functions is interesting
attribute. It allows to work with temporary tables and it make testing
and debugging harder, because lot of errors in embedded queries are
>> We talked about this during PGCon. The idea that seemed to have
>> consensues there was to export the parser similarly to how we build
>> the ecpg parser, that is, a set of perl scripts which take our
>> gram.y as input and modify it to emit something different.
>
> That solves the non-customi
On Mon, Jul 18, 2011 at 02:05:42PM -0400, Alvaro Herrera wrote:
> Excerpts from Jim Nasby's message of dom jul 17 16:31:45 -0400 2011:
>
> > On a somewhat related note, I'd also really like to have the
> > ability to parse things like .sql files externally, to do things
> > like LINT checking.
>
Excerpts from Jim Nasby's message of dom jul 17 16:31:45 -0400 2011:
> On a somewhat related note, I'd also really like to have the ability to parse
> things like .sql files externally, to do things like LINT checking.
We talked about this during PGCon. The idea that seemed to have
consensues t
On Jul 7, 2011, at 11:31 PM, Pavel Stehule wrote:
> a lazy deep SQL validation inside plpgsq functions is interesting
> attribute. It allows to work with temporary tables and it make testing
> and debugging harder, because lot of errors in embedded queries are
> detected too late. I wrote a simple
Hello all,
a lazy deep SQL validation inside plpgsq functions is interesting
attribute. It allows to work with temporary tables and it make testing
and debugging harder, because lot of errors in embedded queries are
detected too late. I wrote a simple module that can to help little
bit. It is base
11 matches
Mail list logo
