Martijn van Oosterhout wrote:
> Please provides natural keys for any of the following:
>
> - A Person
> - A phone call: (from,to,date,time,duration) is not enough
> - A physical address
> - A phone line: (phone numbers arn't unique over time)
> - An internet account: (usernames not unique over ti
Tom Lane wrote:
> What's been suggested in the past is some sort of standalone
> file-format-conversion utility, which could deal with this sort of
stuff
> without having to also deal with all the backend-internal
considerations
> that COPY must handle. So (at least in theory) it'd be simpler and
Simon Riggs wrote
> ISTM we could do some of that with another GUC, lets call it
> prepare_once = on. The system default is to have a prepared statement
> bound to a plan on its first parameter bind. If we set this to "off",
> then the statement will replan each time we bind. This would give us
> b
Greg Stark [EMAIL PROTECTED] writes:
> You more or less missed my entire point.
Only because I am still getting used to how powerful and flexible
Postgres is; but I am working on expanding my horizons.
> In the extreme, no amount of added intelligence in the optimizer is
going
> to
> help it come
Gregory Maxwell <[EMAIL PROTECTED]> wrote:
> The flipside there is that a good set of hinting options may increase
> the amount of detailed feedback we get from users on improvements
> needed in the optimizer. The current knobs are pretty blunt and don't
> do as much as I'd like when trying to tr
Greg Stark <[EMAIL PROTECTED]> writes:
> On the other hand the type I would prefer to see are hints that feed
directly
> into filling in information the planner lacks. This only requires that
the
> user understand his own data and still lets the planner pick the best
plan
> based on the provided in
lto:[EMAIL PROTECTED]
Sent: Tuesday, November 29, 2005 5:23 PM
To: Pollard, Mike
Cc: Qingqing Zhou; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] ice-broker scan thread
On Tue, 2005-11-29 at 09:45 -0500, Pollard, Mike wrote:
> I've implemented this on another database product
You
lto:[EMAIL PROTECTED]
Sent: Tuesday, November 29, 2005 10:06 AM
To: Pollard, Mike
Cc: Qingqing Zhou; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] ice-broker scan thread
On Tue, Nov 29, 2005 at 09:45:30AM -0500, Pollard, Mike wrote:
> Anyway, what I did was the following. When doing a se
First, we need a new term for a thread of execution, that could be a
thread or could be a process, I don't care. When discussing anything
that is to run in parallel, the first thing that pops out of someones
mouth is "Don't you mean (thread/process)?" But that's an
implementation detail and shoul
It Seems To Me.
Here’s a decent list of common
acronyms:
http://www.fun-with-words.com/acronyms.html
Mike Pollard
SUPRA Server SQL Engineering and Support
Cincom Systems, Inc.
Better to
remain silent and be thought a fool than to speak out
, Inc.
Better to remain silent and be thought a fool than to speak out and
remove all doubt.
Abraham Lincoln
-Original Message-
From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 24, 2005 5:57 AM
To: Mario Weilguni
Cc: pgsql-hackers@postgresql.org; Po
If this gets added as a contrib, here's a version of uniqueidentifier
and newid() I wrote that maintains the same format as the SQL Server
version:
CREATE SCHEMA sqlserver
AUTHORIZATION postgres;
GRANT ALL ON SCHEMA sqlserver TO public;
CREATE SEQUENCE sqlserver.uniqueidentifier0
INCREMENT 1
Original Message-
> From: Tino Wildenhain [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 16, 2005 8:43 AM
> To: Pollard, Mike
> Cc: Richard Huxton; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] question about count(b) where b is a custom
type
>
> Pollard, Mik
Richard Huxton wrote:
> Pollard, Mike wrote:
> >>Firstly, if you just want a count, what's wrong with count(1) or
> >>count(*).
> >>
> >
> >
> > Because unless the column does not allow nulls, they will not return
the
> > same value.
>
> Firstly, if you just want a count, what's wrong with count(1) or
> count(*).
>
Because unless the column does not allow nulls, they will not return the
same value.
Mike Pollard
SUPRA Server SQL Engineering and Support
Cincom Systems, Inc.
Better to remain silen
>
> The example given in this thread certainly isn't going to change
> anybody's mind. "Hi, I propose reducing everybody's security because
> my local admins insist on an utterly brain-dead security policy."
>
What's wrong with that? ;)
But seriously, the proposal is not to reduce everybody's s
> I explain myself about running PostGre as admin.
>
> In fact I don't want specifically run PostGre as admin. The problem
is, on
> the computers the application including PostGre will run, I'm not sure
> that
> the user won't have any admin or power user rights. Furthermore, I've
> noticed that o
> and so the most straightforward thing to do is define an empty element
> as meaning a NULL. But this might be objected to on a couple of
grounds:
Can you use a default to allow the user to specify the default value for
an element? May look a little strange, though, if the user specifies a
defa
> and so the most straightforward thing to do is define an empty element
> as meaning a NULL. But this might be objected to on a couple of
grounds:
Can you use a default to allow the user to specify the default value for
an element? May look a little strange, though, if the user specifies a
def
I am not able to quickly find your numeric format, so I'll just throw
this in. MaxDB (I only mention this because the format and algorithms
are now under the GPL, so they can be reviewed by the public) uses a
nifty number format that allows the use memcpy to compare two numbers
when they are in t
20 matches
Mail list logo
