Simon Riggs writes:
> So now the standard for my patches is that I must consider what will
> happen if the xlog is deleted?
When you're messing around with something that affects data integrity, yes.
The long and the short of it is that this patch does reduce our ability
to recover from easily-fo
Robert Haas writes:
> Whee, testing is fun. Second try.
I'm concerned by the fact that neither the original nor the new code
bother to test whether the relation is WAL-loggable. It may be that
ginbuildempty cannot be invoked for temp tables, but it still seems
like an oversight waiting to bite
Hi,
Attached is a small patch to improve the HINT message produced by
CREATE OR REPLACE FUNCTION when the new function definition conflicts
with the old definition. With this patch the hint now includes the
function's name and signature as a directly pasteable SQL command. So,
for example, instead
Simon Riggs writes:
> Add ERROR msg for GLOBAL/LOCAL TEMP is not yet implemented
I don't believe there was actual consensus for this change, and
certainly not for throwing error on both cases.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
On 9 June 2012 16:46, Tom Lane wrote:
> Simon Riggs writes:
>> Add ERROR msg for GLOBAL/LOCAL TEMP is not yet implemented
>
> I don't believe there was actual consensus for this change,
It was hardly a subject of marked disagreement.
> and certainly not for throwing error on both cases.
Why wo
Simon Riggs writes:
> On 9 June 2012 16:46, Tom Lane wrote:
>> I don't believe there was actual consensus for this change,
> It was hardly a subject of marked disagreement.
It was hardly a subject of discussion, as yet.
Personally I'm pretty doubtful about suddenly starting to throw errors
for
Simon Riggs wrote:
> On 9 June 2012 16:46, Tom Lane wrote:
>> Simon Riggs writes:
>>> Add ERROR msg for GLOBAL/LOCAL TEMP is not yet implemented
>>
>> I don't believe there was actual consensus for this change,
>
> It was hardly a subject of marked disagreement.
Regarding GLOBAL, the three co
On Sat, Jun 9, 2012 at 1:09 PM, Kevin Grittner
wrote:
> Simon Riggs wrote:
>> On 9 June 2012 16:46, Tom Lane wrote:
>>> Simon Riggs writes:
Add ERROR msg for GLOBAL/LOCAL TEMP is not yet implemented
>>>
>>> I don't believe there was actual consensus for this change,
>>
>> It was hardly a s
On ons, 2012-06-06 at 11:21 -0400, Tom Lane wrote:
> I'm not really in favor of making /var/run be the out-of-the-box
> default, because it would discriminate against personal/testing
> installations (ie, you couldn't set it up without root privileges).
> It's a reasonable choice for distro-provide
On Saturday, June 09, 2012 11:43:53 PM Peter Eisentraut wrote:
> On ons, 2012-06-06 at 11:21 -0400, Tom Lane wrote:
> > I'm not really in favor of making /var/run be the out-of-the-box
> > default, because it would discriminate against personal/testing
> > installations (ie, you couldn't set it up
"Kevin Grittner" writes:
> Because the current support for temporary tables is relatively
> similar to the standard's description of LOCAL TEMPORARY TABLES, but
> nothing at all like the standard's descri0ption of GLOBAL TEMPORARY
> TABLES.
Um ... did you read the spec before stating that? In th
Peter Eisentraut writes:
> We already have the ability to configure the Unix socket directory in
> postgresql.conf. All you need to do is turn that into a list.
Um, no, it's not quite that simple. In particular, what do you think
should happen on the client side?
I'm inclined to think that we
On lör, 2012-06-09 at 23:45 +0200, Andres Freund wrote:
> On Saturday, June 09, 2012 11:43:53 PM Peter Eisentraut wrote:
> > On ons, 2012-06-06 at 11:21 -0400, Tom Lane wrote:
> > > I'm not really in favor of making /var/run be the out-of-the-box
> > > default, because it would discriminate against
On lör, 2012-06-09 at 18:02 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > We already have the ability to configure the Unix socket directory in
> > postgresql.conf. All you need to do is turn that into a list.
>
> Um, no, it's not quite that simple. In particular, what do you think
> sh
On Sunday, June 10, 2012 12:09:30 AM Peter Eisentraut wrote:
> On lör, 2012-06-09 at 23:45 +0200, Andres Freund wrote:
> > On Saturday, June 09, 2012 11:43:53 PM Peter Eisentraut wrote:
> > > On ons, 2012-06-06 at 11:21 -0400, Tom Lane wrote:
> > > > I'm not really in favor of making /var/run be th
Peter Eisentraut writes:
> On lör, 2012-06-09 at 18:02 -0400, Tom Lane wrote:
>> I'm inclined to think that we should (continue to) have a hardwired
>> "primary" directory, which is the one that libpq is also configured
>> to look in by default.
> Yes.
>> But we could add a run-time-configured
On sön, 2012-06-10 at 00:25 +0200, Andres Freund wrote:
> > > > We already have the ability to configure the Unix socket
> directory in
> > > > postgresql.conf. All you need to do is turn that into a list.
> > > That doesn't help libpq using clients.
> > There is no mandate here to do anything abo
On lör, 2012-06-09 at 18:26 -0400, Tom Lane wrote:
> > Yes, I'm just pointing out that we already have that list
> > (unix_socket_directory in postgresql.conf), except it's currently
> > limited to length 1, because no one has needed a longer one until
> now.
>
> That's not actually quite the same
Magnus Hagander wrote:
I don't have too much hope for them actually changing it - they seem
hell-bent on forcing everybody into metro, and this seems to be yet
another way to do that. But we can always hope...
Looks like they've learnt their lesson...
http://blogs.msdn.com/b/visualstudio/arc
19 matches
Mail list logo
