On Wed, Oct 21, 2015 at 10:24 AM, Dane Foster wrote:
> For posterity here is the final version. I ran it through PostgreSQL
> 9.5beta1 this morning so it's at least syntactically valid. Additionally I
> went w/ a list of INTO targets instead of a RECORD because it's a more
> elegant solution in th
> For posterity here is the final version. I ran it through PostgreSQL
> 9.5beta1 this morning so it's at least syntactically valid. Additionally I
> went w/ a list of INTO targets instead of a RECORD because it's a more
> elegant solution in that it made the code a little less verbose and a
> lit
On Wed, Oct 21, 2015 at 3:20 AM, Pavel Stehule
wrote:
>
>
> 2015-10-21 4:08 GMT+02:00 Dane Foster :
>
>> Since I'm switching to OUT parameters is there any difference
>> (performance/efficiency wise) between using an INTO STRICT
>> RECORD_TYPE_VARIABLE statement which forces me to copy/assign the
2015-10-21 4:08 GMT+02:00 Dane Foster :
> Since I'm switching to OUT parameters is there any difference
> (performance/efficiency wise) between using an INTO STRICT
> RECORD_TYPE_VARIABLE statement which forces me to copy/assign the property
> values from the RECORD to the OUT parameter variables
Since I'm switching to OUT parameters is there any difference
(performance/efficiency wise) between using an INTO STRICT
RECORD_TYPE_VARIABLE statement which forces me to copy/assign the property
values from the RECORD to the OUT parameter variables and simply listing
the OUT parameters, i.e., INTO
On Tue, Oct 20, 2015 at 5:53 PM, Jim Nasby wrote:
> On 10/20/15 11:43 AM, Merlin Moncure wrote:
>
>> *) let's compare notes on your doxygen style code markup. I've been
>> trouble finding a good robust tool that does exactly what I want,
>> curious if you did better.
>>
>
> Related to that (I thi
On 10/20/15 11:43 AM, Merlin Moncure wrote:
*) let's compare notes on your doxygen style code markup. I've been
trouble finding a good robust tool that does exactly what I want,
curious if you did better.
Related to that (I think), you might want to move the documentation out
of the comment bl
On Tue, Oct 20, 2015 at 4:35 PM, John R Pierce wrote:
> On 10/20/2015 1:22 PM, Dane Foster wrote:
>
>> Here is the updated version w/ the feedback incorporated. I'm going to
>> install PostgreSQL 9.6 from source this weekend so I can start
>> testing/debugging.
>>
>
> I would stick with developin
2015-10-20 22:22 GMT+02:00 Dane Foster :
> Here is the updated version w/ the feedback incorporated. I'm going to
> install PostgreSQL 9.6 from source this weekend so I can start
> testing/debugging. Does anyone here have any experience using the pgAdmin
> debugger recently? I ask because it seems
On 10/20/2015 1:22 PM, Dane Foster wrote:
Here is the updated version w/ the feedback incorporated. I'm going to
install PostgreSQL 9.6 from source this weekend so I can start
testing/debugging.
I would stick with developing/debugging on the current release version,
9.4. 9.6 isn't even in
Here is the updated version w/ the feedback incorporated. I'm going to
install PostgreSQL 9.6 from source this weekend so I can start
testing/debugging. Does anyone here have any experience using the pgAdmin
debugger recently? I ask because it seems a little dated (September 26,
2008).
Thanks,
D
On Tue, Oct 20, 2015 at 12:43 PM, Merlin Moncure wrote:
> On Tue, Oct 20, 2015 at 9:45 AM, Dane Foster wrote:
> > Hello,
> >
> > I'm in the very very very very early stages of migrating a MySQL/PHP app
> to
> > PostgreSQL/PHP/Lua. Because we are moving to PostgreSQL one of the [many]
> > things
On Tue, Oct 20, 2015 at 9:45 AM, Dane Foster wrote:
> Hello,
>
> I'm in the very very very very early stages of migrating a MySQL/PHP app to
> PostgreSQL/PHP/Lua. Because we are moving to PostgreSQL one of the [many]
> things I intend to change is to move ALL the SQL code/logic out of the
> applic
2015-10-20 16:45 GMT+02:00 Dane Foster :
> Hello,
>
> I'm in the very very very very early stages of migrating a MySQL/PHP app
> to PostgreSQL/PHP/Lua. Because we are moving to PostgreSQL one of the
> [many] things I intend to change is to move ALL the SQL code/logic out of
> the application layer
14 matches
Mail list logo
