On 6/18/07, Perry, Lance <[EMAIL PROTECTED]> wrote:
We currently have a need for a PostgreSQL Developer to fill a permanent
requirement with our company here in San Diego.
In the future, please post to pgsql-jobs. Thank you.
--
Jonah H. Harris, Software Architect | phone: 732.331.1324
Enterpr
We currently have a need for a PostgreSQL Developer to fill a permanent
requirement with our company here in San Diego. Details below. Please
contact Lance Perry at 858-550-1658 or [EMAIL PROTECTED] for further
info.
Title: SQL Server/PostgreSQL Database Developer
This position involves crea
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Would someone please explain why we are considering this so far past
> features freeze, and who suggtested that the 8.3->8.4 upgrade being a binary
> upgrade was anything more than a pipe dream?
Simon just updated a patch he had originally submitted o
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Would someone please explain why we are considering this so far past
> features freeze, and who suggtested that the 8.3->8.4 upgrade being a binary
> upgrade was anything more than a pipe dream?
Well, Greg had left further squeezing of numerics as an ope
Simon Riggs wrote:
> On Mon, 2007-06-18 at 11:55 -0400, Tom Lane wrote:
> > "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > > Since this is your idea, would you like to do this, or should I?
> >
> > Go for it.
>
> OK
>
> > I'm not actually convinced this is worth spending time on,
> > as Greg St
"Tom Lane" <[EMAIL PROTECTED]> writes:
> It's case-sensitive. We had that argument already, but I still think
> this decision was wrong.
I thought the consensus was that it should change.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---(end
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> I think representing zero as compactly as possible is worth the trouble,
Either of these proposals can do that in 2 bytes.
regards, tom lane
---(end of broadcast)---
TIP 4: Have yo
On Mon, 2007-06-18 at 12:44 -0400, Tom Lane wrote:
> I wrote:
> > Gregory Stark <[EMAIL PROTECTED]> writes:
> >> Anything shorter than the shortest possible numeric representation can
> >> implicitly be interpreted as some alternate compact representation. I
> >> already had a patch that stored sma
Am Montag, 18. Juni 2007 19:03 schrieb Tom Lane:
> Standard according to whom?
ISO 31 a.k.a. SI
> In time-related contexts (eg ISO 8601) I'd expect just "h" "m" and "s".
ISO 8601 appears to use a slightly different syntax for writing timespans. I
would not object if anyone added support for th
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> I'm pretty sure a lot of people would initially be confused why anyone would
> write time in meters, let alone those that might associate it with memory
> units. In my subjective view (and I acknowledge that we have all been
> educated in differ
Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Once you have an XML plan what can you do with it? All you can do is parse it
>> into constituent bits and display it. You cant do any sort of comparison
>> between plans, aggregate results, search for plans matching constraints, etc.
>
Am Montag, 18. Juni 2007 18:16 schrieb Alvaro Herrera:
> - We do allow preffixes in certain cases.
It would certainly be fun to have a general units system, which you could use
for configuration and data in general. But that would definitely require
that we stay strict on what we allow, or you
On Jun 18, 2007, at 12:58 AM, Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Christopher Browne wrote:
That won't help; that would introduce the "embarrassment" of
having a
known default password.
No it wouldn't unless the packagers set it up to do that. My point is
that whe
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Montag, 18. Juni 2007 16:16 schrieb Tom Lane:
>> It seems that time-based GUC variables can be spelled like
>> 1h but not 1hr
>> 1minbut not 1m
>> 1s but not 1sec
> The left columns are
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> 1) rename FULLTEXT to TEXT SEARCH in SQL command
> Working on it, I found rather obvious undesired side-effect: if TEXT
> becomes a keyword then any output of name of text type becomes
> quoted. Even if TEXT is in unreserved_keyword list.
Yeah, I was
I wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Anything shorter than the shortest possible numeric representation can
>> implicitly be interpreted as some alternate compact representation. I
>> already had a patch that stored small integers in a single
>> NumericDigit without any numeric h
Am Montag, 18. Juni 2007 16:16 schrieb Tom Lane:
> It seems that time-based GUC variables can be spelled like
> 1h but not 1hr
> 1minbut not 1m
> 1s but not 1sec
The left columns are the standard units. The right columns are just rando
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> - I was bitten by this too, not long ago, and took me a while to
> understand why. Should we at least log a HINT or something?
Yeah, a HINT listing the allowed spellings of the unit would go a long
way here.
> However, preffixing with M or K does
Tom Lane wrote:
> It seems that time-based GUC variables can be spelled like
> 1h but not 1hr
> 1minbut not 1m
> 1s but not 1sec
> This is inconsistent and confusing. I don't object to the ones on the
> left as being the standard spellings fo
Gregory Stark <[EMAIL PROTECTED]> writes:
> Anything shorter than the shortest possible numeric representation can
> implicitly be interpreted as some alternate compact representation. I already
> had a patch that stored small integers in a single NumericDigit without any
> numeric header at all.
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> The OID trick doesn't work very well either.
> expn "OID trick"?
See htup.h concerning where we stick OID into a tuple that has OID.
regards, tom lane
---(end of
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I had a thought though: it's possible to reduce the header overhead for
> typical-size numbers without giving up the ability to store large ones.
> This is because the POS/NEG/NAN sign possibilities leave one unused bit
> pattern. Hence:
I had a whack an
On Mon, 2007-06-18 at 11:55 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > Since this is your idea, would you like to do this, or should I?
>
> Go for it.
OK
> I'm not actually convinced this is worth spending time on,
> as Greg Stark's 1-byte-varlena patch already save
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Since this is your idea, would you like to do this, or should I?
Go for it. I'm not actually convinced this is worth spending time on,
as Greg Stark's 1-byte-varlena patch already saved more for typical
numerics than this will.
On Mon, 2007-06-18 at 17:49 +0200, Andreas Pflug wrote:
> I wonder if the currently waiting patch isn't Good Enough for
> 999. % of use cases, and "all" others can use numeric
> instead of numeric(1000,800) or so. Especially since there are many
> patches waiting that do need furth
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> In any case, no capability is lost, unlike the original proposal; and
>> this would be much less invasive than the original patch since there's
>> no need to play tricks with the content of the digit array.
> I wonder if the currently
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> Why do we require that t_hoff is MAXALIGNed? ISTM that if the first
>> field in a tuple doesn't require alignment, it could be stored
>> immediately after the null bitmap, without padding.
>
> Then the in
On Mon, 2007-06-18 at 11:32 -0400, Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
> > Simon Riggs wrote:
> >> The objections to applying this patch originally were:
> >> 2. it would restrict number of digits to 508 and there are allegedly
> >> some people that want to store > 508 digit
Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
>
>> Simon Riggs wrote:
>>
>>> The objections to applying this patch originally were:
>>> 2. it would restrict number of digits to 508 and there are allegedly
>>> some people that want to store > 508 digits.
>>>
>>>
>> If 50
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> The objections to applying this patch originally were:
>> 2. it would restrict number of digits to 508 and there are allegedly
>> some people that want to store > 508 digits.
>>
> If 508 digits are not enough, are1000 digits be suff
Andreas Pflug wrote:
Simon Riggs wrote:
The objections to applying this patch originally were:
2. it would restrict number of digits to 508 and there are allegedly
some people that want to store > 508 digits.
If 508 digits are not enough, are1000 digits be sufficient? Both limits
appear quit
On Mon, 2007-06-18 at 10:54 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > We've changed the on-disk database format in 8.3, so we have an
> > opportunity to change other things also. There is a patch thats been on
> > the patch queue for some time called numeric508, submitt
On Mon, 2007-06-18 at 16:56 +0200, Andreas Pflug wrote:
> Simon Riggs wrote:
> > The objections to applying this patch originally were:
> > 2. it would restrict number of digits to 508 and there are allegedly
> > some people that want to store > 508 digits.
> >
> If 508 digits are not enough, ar
Simon Riggs wrote:
> The objections to applying this patch originally were:
> 2. it would restrict number of digits to 508 and there are allegedly
> some people that want to store > 508 digits.
>
If 508 digits are not enough, are1000 digits be sufficient? Both limits
appear quite arbitrary to me
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> We've changed the on-disk database format in 8.3, so we have an
> opportunity to change other things also. There is a patch thats been on
> the patch queue for some time called numeric508, submitted Dec 2005;
I thought that idea had been rejected long si
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Why do we require that t_hoff is MAXALIGNed? ISTM that if the first
> field in a tuple doesn't require alignment, it could be stored
> immediately after the null bitmap, without padding.
Then the intra-tuple alignment would be unpredictable.
The
We've changed the on-disk database format in 8.3, so we have an
opportunity to change other things also. There is a patch thats been on
the patch queue for some time called numeric508, submitted Dec 2005;
I've updated this patch now for 8.3 to remove bit rot (an hour's work).
This is posted to pgsq
Am Dienstag, 22. Mai 2007 05:58 schrieb Tom Lane:
> Okay, I spent some time googling this question, and I can't find any
> suggestion that any ARM variant uses non-IEEE-compliant float format.
Some news I'm picking up at DebConf is that the existing Debian "arm" port
will be replaced by a new "ar
It seems that time-based GUC variables can be spelled like
1h but not 1hr
1minbut not 1m
1s but not 1sec
This is inconsistent and confusing. I don't object to the ones on the
left as being the standard spellings for printout, but if we'
On Mon, 18 Jun 2007, Simon Riggs wrote:
Smoother checkpoints mean smaller resource queues when a burst coincides
with a checkpoint, so anybody with throughput-maximised or bursty apps
should want longer, smooth checkpoints.
True as long as two conditions hold:
1) Buffers needed to fill alloc
* Jeremy Drake ([EMAIL PROTECTED]) wrote:
> The crux of this seems to be two-fold:
> 1. If dblink is installed, an untrusted user could use it to gain
> privileges, either using trust/ident auth (you have a superuser named
> after the account the postmaster is runing as), or can be scripted to
> br
Hi,
On Mon, 2007-06-18 at 01:58 -0400, Tom Lane wrote:
> Practically every existing packaging of PG tries to run initdb as a
> hidden, behind-the-scenes, definitely not-interactive procedure.
Also, from RPM perspective: RPMs are *not* interactive, and will *never*
be. So we cannot ask user a pas
On Wed, 2007-06-13 at 14:01 -0400, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Arguably this is a bug if it's causing pg_admin difficulties in parsing the
> > output. Even for a user in an environment where, for example, he has several
> > identical schemas and may be accidental
On Sun, 2007-06-17 at 01:36 -0400, Greg Smith wrote:
> The last project I was working on, any checkpoint that caused a
> transaction to slip for more than 5 seconds would cause a data loss. One
> of the defenses against that happening is that you have a wicked fast
> transaction rate to clear
44 matches
Mail list logo
