I wrote:
> I took a stab at doing that, just to see what it might look like.
> I thought it comes out pretty well, really -- see what you think.
Hearing nothing further, I pushed that after another round of
copy-editing. There's still plenty of time to revise it if
anybody has further comments.
"David G. Johnston" writes:
> I do agree that the delineation of "returns records or not" is not ideal
> here. SELECT, then INSERT/UPDATE/DELETE (due to their shared RETURNING
> dynamic), then "DML commands", then "DMS exceptions" (these last two
> ideally leveraging the conceptual work noted abo
On Fri, Mar 12, 2021 at 1:36 PM Tom Lane wrote:
> Pavel Stehule writes:
> > pá 12. 3. 2021 v 21:08 odesílatel Tom Lane napsal:
> >> I attach a v3 that I like better, although there's room to disagree
> >> about that.
>
> > I am not sure if people can understand the "optimizable command" term.
>
pá 12. 3. 2021 v 21:36 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > pá 12. 3. 2021 v 21:08 odesílatel Tom Lane napsal:
> >> I attach a v3 that I like better, although there's room to disagree
> >> about that.
>
> > I am not sure if people can understand the "optimizable command" term
Pavel Stehule writes:
> pá 12. 3. 2021 v 21:08 odesílatel Tom Lane napsal:
>> I attach a v3 that I like better, although there's room to disagree
>> about that.
> I am not sure if people can understand the "optimizable command" term. More
> common categories are DML, DDL and SELECT. Maybe it is
Hi
pá 12. 3. 2021 v 21:08 odesílatel Tom Lane napsal:
> I looked over the v2 patch. Parts of it seem like improvements but
> other parts definitely don't. In particular, I thought you introduced
> a great deal of confusion in 43.5.2 (Executing a Command with No Result).
> The statement that yo
I looked over the v2 patch. Parts of it seem like improvements but
other parts definitely don't. In particular, I thought you introduced
a great deal of confusion in 43.5.2 (Executing a Command with No Result).
The statement that you can write a non-result-returning SQL command as-is
is true in g
On 3/9/21 1:08 PM, Tom Lane wrote:
David Steele writes:
1) PL/SQL seems to be used in a few places where I believe PL/pgSQL is
meant. This was pre-existing but now seems like a good opportunity to
fix it, unless I am misunderstanding.
PL/SQL is Oracle's function language, which PL/pgSQL is mo
On Tue, Mar 9, 2021 at 10:45 AM Pavel Stehule
wrote:
>
>
> út 9. 3. 2021 v 18:03 odesílatel David Steele
> napsal:
>
>> On 11/30/20 10:37 AM, Pavel Stehule wrote:
>> > po 30. 11. 2020 v 16:06 odesílatel David G. Johnston
>> >
>> > ok
>> This patch looks reasonable to me overall.
>>
>> A few comm
David Steele writes:
> 1) PL/SQL seems to be used in a few places where I believe PL/pgSQL is
> meant. This was pre-existing but now seems like a good opportunity to
> fix it, unless I am misunderstanding.
PL/SQL is Oracle's function language, which PL/pgSQL is modeled on.
At least some of the
út 9. 3. 2021 v 18:03 odesílatel David Steele napsal:
> On 11/30/20 10:37 AM, Pavel Stehule wrote:
> > po 30. 11. 2020 v 16:06 odesílatel David G. Johnston
> >
> > ok
> This patch looks reasonable to me overall.
>
> A few comments:
>
> 1) PL/SQL seems to be used in a few places where I believe PL
On 11/30/20 10:37 AM, Pavel Stehule wrote:
po 30. 11. 2020 v 16:06 odesílatel David G. Johnston
ok
This patch looks reasonable to me overall.
A few comments:
1) PL/SQL seems to be used in a few places where I believe PL/pgSQL is
meant. This was pre-existing but now seems like a good opportu
po 30. 11. 2020 v 16:06 odesílatel David G. Johnston <
david.g.johns...@gmail.com> napsal:
> On Mon, Nov 30, 2020 at 12:51 AM Pavel Stehule
> wrote:
>
>>
>>
>> po 30. 11. 2020 v 4:24 odesílatel David G. Johnston <
>> david.g.johns...@gmail.com> napsal:
>>
>>> On Thu, Nov 26, 2020 at 12:49 AM Pave
On Mon, Nov 30, 2020 at 12:51 AM Pavel Stehule
wrote:
>
>
> po 30. 11. 2020 v 4:24 odesílatel David G. Johnston <
> david.g.johns...@gmail.com> napsal:
>
>> On Thu, Nov 26, 2020 at 12:49 AM Pavel Stehule
>> wrote:
>>
>>>
>>>
>>> čt 26. 11. 2020 v 6:41 odesílatel David G. Johnston <
>>> david.g.j
po 30. 11. 2020 v 4:24 odesílatel David G. Johnston <
david.g.johns...@gmail.com> napsal:
> On Thu, Nov 26, 2020 at 12:49 AM Pavel Stehule
> wrote:
>
>>
>>
>> čt 26. 11. 2020 v 6:41 odesílatel David G. Johnston <
>> david.g.johns...@gmail.com> napsal:
>>
>>> Hackers,
>>>
>>> Bug # 16519 [1] is an
On Thu, Nov 26, 2020 at 12:49 AM Pavel Stehule
wrote:
>
>
> čt 26. 11. 2020 v 6:41 odesílatel David G. Johnston <
> david.g.johns...@gmail.com> napsal:
>
>> Hackers,
>>
>> Bug # 16519 [1] is another report of confusion regarding trying to use
>> parameters in improper locations - specifically the
čt 26. 11. 2020 v 6:41 odesílatel David G. Johnston <
david.g.johns...@gmail.com> napsal:
> Hackers,
>
> Bug # 16519 [1] is another report of confusion regarding trying to use
> parameters in improper locations - specifically the SET ROLE command within
> pl/pgsql. I'm re-attaching the doc patch
Hackers,
Bug # 16519 [1] is another report of confusion regarding trying to use
parameters in improper locations - specifically the SET ROLE command within
pl/pgsql. I'm re-attaching the doc patch and am adding it to the
commitfest.
David J.
[1]
https://www.postgresql.org/message-id/16519-9ef04
18 matches
Mail list logo
