Dominique Devienne writes:
> On Fri, Feb 21, 2025 at 3:44 PM Tom Lane wrote:
>> DROP OWNED also removes relevant permission entries (which can be
>> thought of as things owned by the role, if you hold your head at
>> the right angle). See its man page.
> Except when it doesn't... I'm doing the
On Tuesday, April 29, 2025, Tim Starling wrote:
>
>
> This is a public interface and there may be callers in code that I don't
> have access to.
>
You might help your cause by sharing examples of how client code uses your
driver to perform upsert that runs into this limitation.
David J.
David Rowley writes:
> Another thought is that you can have an UPDATE with a RETURNING
> clause. An unqualified column defaults to NEW even though you could
> argue it's ambiguous due to OLD (as of 80feb727c). Likely we were
> forced into making it work that way through not wanting to force
> ever
On Fri, Feb 21, 2025 at 3:44 PM Tom Lane wrote:
> Dominique Devienne writes:
> > On Fri, Feb 21, 2025 at 3:33 PM Tom Lane wrote:
> >> REASSIGN OWNED then DROP OWNED is the recommended path.
>
> > Hi. Am I missing something? foobar does not OWN anything in this case.
> > So I don't see how these
On Tue, 29 Apr 2025 at 01:54, Tom Lane wrote:
> I do actually have some sympathy for your proposal after thinking
> about it a bit more, but the argument I would use is "the behavior
> of the ON CONFLICT UPDATE SET list should be as much as possible like
> the behavior of an ordinary UPDATE's SET
On 29/4/25 16:36, Laurenz Albe wrote:
On Tue, 2025-04-29 at 08:36 +1000, Tim Starling wrote:
My code would be like
function upsert( $table, $names, $values, $key, $set ) {
if ( $this->type === 'mysql' ) {
$conflict = 'ON DUPLICATE KEY UPDATE';
} else {
$conflict
Hi,
Checking the documents .
Post fetching Boolean can we have a trigger or function which can build up
the where filter clause?
Or can i have a case statement in the Using which can return such
statements?
On Fri, Apr 25, 2025 at 7:02 PM Dominique Devienne
wrote:
> On Fri, Apr 25, 2025 at 3:
