On Sun, May 21, 2017 at 5:37 PM, Tom Lane wrote:
> Riaan Stander writes:
>> The intended use is use-once. The reason is that the statements might
>> differ per call, especially when we start doing updates. The ideal would
>> be to just issue the sql statements, but I was trying to cut down on
>>
Simon Riggs writes:
> It sounds like you don't know about anonymous code blocks with DO
> https://www.postgresql.org/docs/devel/static/sql-do.html
No, the problem was that there are also some parameters to be passed
in from the application, and DO doesn't take any parameters; so that
would requir
On 22 May 2017 at 09:06, Riaan Stander wrote:
It sounds like you don't know about anonymous code blocks with DO
https://www.postgresql.org/docs/devel/static/sql-do.html
Yes I do know about that feature. My first implemented generated an
anonymous code block, but to my utter dismay once I tr
On 22 May 2017 at 09:06, Riaan Stander wrote:
>> It sounds like you don't know about anonymous code blocks with DO
>> https://www.postgresql.org/docs/devel/static/sql-do.html
>>
>
> Yes I do know about that feature. My first implemented generated an
> anonymous code block, but to my utter dismay
On 22 May 2017 at 03:14, Riaan Stander wrote:
Riaan Stander writes:
The intended use is use-once. The reason is that the statements might
differ per call, especially when we start doing updates. The ideal would
be to just issue the sql statements, but I was trying to cut down on
network call
On 22 May 2017 at 03:14, Riaan Stander wrote:
>
>> Riaan Stander writes:
>>>
>>> The intended use is use-once. The reason is that the statements might
>>> differ per call, especially when we start doing updates. The ideal would
>>> be to just issue the sql statements, but I was trying to cut down
Riaan Stander writes:
The intended use is use-once. The reason is that the statements might
differ per call, especially when we start doing updates. The ideal would
be to just issue the sql statements, but I was trying to cut down on
network calls. To batch them together and get output from on
Riaan Stander writes:
> The intended use is use-once. The reason is that the statements might
> differ per call, especially when we start doing updates. The ideal would
> be to just issue the sql statements, but I was trying to cut down on
> network calls. To batch them together and get output
Riaan Stander writes:
I've come up with generating functions on the go, but I'm concerned about
the performance impact of this. I first wanted to use an anonoumys code
block, but then I cannot do parameter binding from npgsql.
...
Is there a better way I'm missing and is "temp" function creati
Riaan Stander writes:
> I've come up with generating functions on the go, but I'm concerned about
> the performance impact of this. I first wanted to use an anonoumys code
> block, but then I cannot do parameter binding from npgsql.
> ...
> Is there a better way I'm missing and is "temp" functio
Good day
I’ve got a performance and best practice question. We’re busy writing our
persistence framework for our application port to PostgreSQL.
We have business entities that are split over multiple tables and in an
effort to not have multiple trips to the database we’re trying to batch
these
11 matches
Mail list logo
