On 11/30/2010 09:57 AM, Csaba Nagy wrote:
So it is really an ideological thing and not lack of demand or
implementation attempts... I for myself can't write working C code
anyway, so I got my peace with the workaround - I wish you good luck
arguing Tom :-)
We need a convincing use case for
Robert Haas writes:
> On Mon, Nov 29, 2010 at 11:25 PM, Andrew Dunstan wrote:
>> I can't say I'd be excited by this feature. In quite a few years of writing
>> SQL I don't recall ever wanting such a gadget.
> It's something I've wanted periodically, though not badly enough to do
> the work to ma
On Tue, Nov 30, 2010 at 5:02 AM, Heikki Linnakangas
wrote:
> On 30.11.2010 11:55, Heikki Linnakangas wrote:
>>
>> On 27.11.2010 21:31, Bruce Momjian wrote:
>>>
>>> Heikki Linnakangas wrote:
There's no on-disk format changes, except for the additional flag in the
page headers, so thi
On Tue, Nov 30, 2010 at 4:25 AM, Csaba Nagy wrote:
> The workaround recommended some time ago by Tom is:
>
> DELETE FROM residents_of_athens WHERE ctid = any(array(SELECT ctid FROM
> residents_of_athens ORDER BY ostracism_votes DESC LIMIT 1));
>
> It is about as efficient as the requested feature
On Tue, Nov 30, 2010 at 08:13:37PM +0900, Itagaki Takahiro wrote:
> On Tue, Nov 30, 2010 at 18:18, David Fetter wrote:
> >> It expands all tables (and views) in tab-completion after INSERT,
> >> UPDATE, and DELETE FROM. Is it an intended change?
>
> I found it was a simple bug; we need ( ) aroun
On Mon, Nov 29, 2010 at 10:06 PM, Robert Haas wrote:
> On Mon, Nov 29, 2010 at 9:37 PM, Josh Kupershmidt wrote:
>> I actually hadn't thought of that, for some reason.
>>
>> We used to similarly recommend that people handle TRUNCATE privileges
>> with a security definer function. That doesn't mean
On Mon, Nov 29, 2010 at 10:50 PM, Marti Raudsepp wrote:
> On Tue, Nov 30, 2010 at 05:09, Jaime Casanova wrote:
>> at least IMHO the only sensible way that LIMIT is usefull is with
>> an ORDER BY clause with make the results very well defined...
>
> DELETE with LIMIT is also useful for deleting th
On Mon, Nov 29, 2010 at 9:57 PM, Robert Haas wrote:
> 1. Pin each visibility map page. If any VM_BECOMING_ALL_VISIBLE bits
> are set, take the exclusive content lock for long enough to clear
> them.
I wonder what the performance hit will be to workloads with contention
and if this feature should
Hi all,
The workaround recommended some time ago by Tom is:
DELETE FROM residents_of_athens WHERE ctid = any(array(SELECT ctid FROM
residents_of_athens ORDER BY ostracism_votes DESC LIMIT 1));
It is about as efficient as the requested feature would be, just uglier
to write down. I use it all the
On Tue, Nov 30, 2010 at 18:18, David Fetter wrote:
>> It expands all tables (and views) in tab-completion after INSERT,
>> UPDATE, and DELETE FROM. Is it an intended change?
I found it was a simple bug; we need ( ) around selcondition.
In addition, I modified your patch a bit:
* I added a sepa
On 30.11.2010 11:55, Heikki Linnakangas wrote:
On 27.11.2010 21:31, Bruce Momjian wrote:
Heikki Linnakangas wrote:
There's no on-disk format changes, except for the additional flag in the
page headers, so this does not affect pg_upgrade. However, if there's
any "invalid" keys in the old index b
On 27.11.2010 21:31, Bruce Momjian wrote:
Heikki Linnakangas wrote:
There's no on-disk format changes, except for the additional flag in the
page headers, so this does not affect pg_upgrade. However, if there's
any "invalid" keys in the old index because of an incomplete insertion,
the new code
Itagaki Takahiro writes:
> client_encoding won't work at all because read_sql_queries_from_file()
> uses pg_verifymbstr(), that is verify the input with *server_encoding*.
>
> Even if we replace it with pg_verify_mbstr(client_encoding, ...) and
> pg_do_encoding_conversion(from client_encoding to s
Itagaki Takahiro writes:
> I think there are two topics here:
> 1. Do we need to restrict locations in which sql files are executable?
> 2. Which is better, pg_execute_sql_file() or EXECUTE pg_read_file() ?
>
> There are no discussion yet for 1, but I think we need some restrictions
Well, as
On Tue, Nov 30, 2010 at 05:48:04PM +0900, Itagaki Takahiro wrote:
> On Wed, Nov 24, 2010 at 12:21, David Fetter wrote:
> > Please find attached a patch changing both this and "updateable" to
> > "updatable," also per the very handy git grep I just learned about :)
>
> I think the patch has two is
On Wed, Nov 24, 2010 at 12:21, David Fetter wrote:
> Please find attached a patch changing both this and "updateable" to
> "updatable," also per the very handy git grep I just learned about :)
I think the patch has two issues to be fixed.
It expands all tables (and views) in tab-completion after
101 - 116 of 116 matches
Mail list logo
