Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm not sure we could rely on the behavior if we declared
>> pg_type.typtype as an enum type ... and if we don't, there's not
>> much point.
> I was thinking C enums:
> enum typtype_type {
> TYPTYPE_BASE = 'b',
> TYPTYP
Tom Lane wrote:
> > Why not enums? ;-)
>
> Well, macros is how we do it elsewhere for "char" system columns.
> I'm not sure we could rely on the behavior if we declared
> pg_type.typtype as an enum type ... and if we don't, there's not
> much point.
I was thinking C enums:
enum typtype_type {
<[EMAIL PROTECTED]> writes:
>> It's important to get the *right* interface into the first release
>> that has it.
> Agreed, that's why I proposed the right interface to begin with :-)
I don't necessarily object to PQexecf() as a shortcut for some
multi-step operation, but I don't think you've g
Mark Dilger wrote:
Bruce Momjian wrote:
Added to TODO:
* Fix cases where invalid byte encodings are accepted by the
database,
but throw an error on SELECT
http://archives.postgresql.org/pgsql-hackers/2007-03/msg00767.php
Is anyone working on fixing this bug?
Hi, has a
Peter Eisentraut <[EMAIL PROTECTED]> writes:
>>> I just realized that I need to check every usage of typtype to be
>>> sure that the enums patch is sane. So, barring objection, I intend
>>> to take this opportunity to make the code stop referring directly
>>> to 'b', 'c' etc whereever possible. A
Bruce Momjian wrote:
Added to TODO:
* Fix cases where invalid byte encodings are accepted by the database,
but throw an error on SELECT
http://archives.postgresql.org/pgsql-hackers/2007-03/msg00767.php
Is anyone working on fixing this bug?
Hi, has anyone v
Bruce Momjian wrote:
> > I just realized that I need to check every usage of typtype to be
> > sure that the enums patch is sane. So, barring objection, I intend
> > to take this opportunity to make the code stop referring directly
> > to 'b', 'c' etc whereever possible. Any objections to these n
On Sat, Mar 31, 2007 at 07:58:34PM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > What say we put one in pre-emptively for TYPTYPE_ARRAY?
>
> When and if the patch appears, you can add it ;-). I'm just intending a
> search-and-replace at the moment.
Like this?
Cheers,
D
-
David Fetter <[EMAIL PROTECTED]> writes:
> What say we put one in pre-emptively for TYPTYPE_ARRAY?
When and if the patch appears, you can add it ;-). I'm just intending a
search-and-replace at the moment.
regards, tom lane
---(end of broadcast)---
On Sat, Mar 31, 2007 at 07:13:20PM -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > I wrote:
> > > David Fetter <[EMAIL PROTECTED]> writes:
> > >> What parts of the code would need a once-over?
> >
> > > A lot :-( ... probably every place that touches typtype or typelem would
> > > need at leas
> [EMAIL PROTECTED] wrote:
> > > I note that the nominal schedule
> > > http://www.postgresql.org/developer/roadmap
> > > says that all major proposals should have been made and reviewed at
> > > least a month ago.
> >
> >
> > Consider me spanked... (and quit giggling Bruce).
>
> Awe, you got
Andrew Dunstan wrote:
> [EMAIL PROTECTED] wrote:
> >> It's important to get the *right* interface into the first release
> >> that has it.
> >>
> >
> > Agreed, that's why I proposed the right interface to begin with :-)
> >
>
> Maybe the first thing we might usefully do would be to document
Tom Lane wrote:
> I wrote:
> > David Fetter <[EMAIL PROTECTED]> writes:
> >> What parts of the code would need a once-over?
>
> > A lot :-( ... probably every place that touches typtype or typelem would
> > need at least a look. It'd be a good idea to take the opportunity to
> > start using mac
[EMAIL PROTECTED] wrote:
It's important to get the *right* interface into the first release
that has it.
Agreed, that's why I proposed the right interface to begin with :-)
Maybe the first thing we might usefully do would be to document
PQExpBuffer. And you can send in a patch for t
[EMAIL PROTECTED] wrote:
> > I note that the nominal schedule
> > http://www.postgresql.org/developer/roadmap
> > says that all major proposals should have been made and reviewed at
> > least a month ago.
>
>
> Consider me spanked... (and quit giggling Bruce).
Awe, you got me. :-)
FYI, I sun
I wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
>> What parts of the code would need a once-over?
> A lot :-( ... probably every place that touches typtype or typelem would
> need at least a look. It'd be a good idea to take the opportunity to
> start using macros for the values of typtype,
Tom Lane wrote:
> I seem to remember that we'd agreed that autovacuum should ignore any
> globally set statement_timeout, on the grounds that a poorly chosen
> setting could indefinitely prevent large tables from being vacuumed.
On a vaguely related matter, should programs such as pg_dump, vacuumd
> It's important to get the *right* interface into the first release
> that has it.
Agreed, that's why I proposed the right interface to begin with :-)
> The day before feature freeze is way too late for
> blue-sky design IMHO.
Ok, I can certainly bring this up again in the next release cyc
This may have the nice side effect of pushing 'possibly patented' technologies
into the FOSS realm, but again I wonder what the duration/persistence of
Oracle's committment is?
I think I will ask our lawyers to review this.
- Luke
Msg is shrt cuz m on ma treo
-Original Message-
From:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> Yes, it may work. Do we need to take some extra care because
> proc-xmin is set while holding SHARED lock on proc array ?
Good point. I'm envisioning a procarray.c function along the
lines of
bool TransactionHasSnapshot(xid)
which returns tr
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I would be worried if I were you (or Joshua Drake for that matter): does
> the agreement apply to commercial companies deriving products from
> PostgreSQL as well?
Interesting point. It's doubtless unwise to take this press release as
being an accurate
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> If Oracle truly (or IBM etc..) really was interested in "Protecting
> Linux" or other FOSS software, they would put the patent in the public
> domain.
No, you miss the point of OIN. Doing the above might make FOSS
developers free from the particul
On 3/31/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Hmm ... only if it's already set inVacuum true ... there's a window
where it has not.
I wonder whether we could change CIC so that the "reference
snapshot" lists only transactions that are running and have already
determined their serializable sn
Alvaro Herrera wrote:
Luke Lonergan wrote:
Bruce,
This is big news - has anyone checked to see if the agreement for the OIN is
in perpetuity? Or is their agreement to not pursue patents only for as long
as they are members?
I would be worried if I were you (or Joshua Drake for that matter):
Luke Lonergan wrote:
> Bruce,
>
> This is big news - has anyone checked to see if the agreement for the OIN is
> in perpetuity? Or is their agreement to not pursue patents only for as long
> as they are members?
I would be worried if I were you (or Joshua Drake for that matter): does
the agreeme
Andrew Dunstan wrote:
Luke Lonergan wrote:
Bruce,
This is big news - has anyone checked to see if the agreement for the
OIN is
in perpetuity? Or is their agreement to not pursue patents only for
as long
as they are members?
I'm sure they would be estopped from enforcing a patent against
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> On 3/31/07, Tom Lane <[EMAIL PROTECTED]> wrote:
>> Can you give a specific example?
> txn1 - CREATE INDEX CONCURRENTLY (takes ShareUpdateExclusiveLock)
> txn2 - VACUUM ANALYZE (waits on ShareUpdateExclusiveLock)
> tnx1 - waits for txn2 to complete in
Luke Lonergan wrote:
Bruce,
This is big news - has anyone checked to see if the agreement for the OIN is
in perpetuity? Or is their agreement to not pursue patents only for as long
as they are members?
I'm sure they would be estopped from enforcing a patent against someone
who relied on th
Bruce,
This is big news - has anyone checked to see if the agreement for the OIN is
in perpetuity? Or is their agreement to not pursue patents only for as long
as they are members?
- Luke
On 3/30/07 10:43 AM, "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> Here is a surprising article about how
On 3/31/07, Tom Lane <[EMAIL PROTECTED]> wrote:
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> Isn't CREATE INDEX CONCURRENTLY prone deadlock conditions ?
Can you give a specific example?
txn1 - CREATE INDEX CONCURRENTLY (takes ShareUpdateExclusiveLock)
txn2 - VACUUM ANALYZE (waits on ShareU
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Russell Smith wrote:
I agree with this, it reduces the long running transaction problem a
little where the user forgot to commit/rollback their session. I may be
worth having a transaction_timeout as well, and setting it to link a
Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Russell Smith wrote:
I agree with this, it reduces the long running transaction problem a
little where the user forgot to commit/rollback their session. I may be
worth having a transaction_timeout as well, and setting it to link a
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Russell Smith wrote:
>> I agree with this, it reduces the long running transaction problem a
>> little where the user forgot to commit/rollback their session. I may be
>> worth having a transaction_timeout as well, and setting it to link a few
>>
<[EMAIL PROTECTED]> writes:
> 2) It's important to get the interface into a near-future release so
> that client applications can start using it soon.
It's important to get the *right* interface into the first release
that has it. The day before feature freeze is way too late for
blue-sky design
Russell Smith wrote:
Joshua D. Drake wrote:
Hello,
I ran into an interesting problem with a customer today. They are
running Jabber XCP (not the one we use). Unfortunately, the product
has a bug that causes it to leave connections persistent in a
transaction state. This is what it does:
BE
"Pavan Deolasee" <[EMAIL PROTECTED]> writes:
> Isn't CREATE INDEX CONCURRENTLY prone deadlock conditions ?
Can you give a specific example? The deadlock code will grant locks
out-of-order in cases where the alternative is to abort somebody.
I think you may be describing a missed opportunity in th
> Way too late for 8.3 --- if we were going to do something like this,
> we should think first and program later. In particular, blindly
> adopting the sprintf format string definition doesn't seem very helpful.
> The sorts of escapes I'd want to have are "properly quoted SQL
> identifier", "prope
On Sat, 2007-03-31 at 17:45 +0530, Pavan Deolasee wrote:
>
> Isn't CREATE INDEX CONCURRENTLY prone deadlock conditions ?
> I saw one with VACUUM today. But I think it can happen with other
> commands like VACUUM FULL, CLUSTER, CREATE INDEX
> CONCURRENTLY and so on. These commands conflict on the
Isn't CREATE INDEX CONCURRENTLY prone deadlock conditions ?
I saw one with VACUUM today. But I think it can happen with other
commands like VACUUM FULL, CLUSTER, CREATE INDEX
CONCURRENTLY and so on. These commands conflict on the
ShareUpdateExclusiveLock held by CIC and hence would wait for
CIC to
Joshua D. Drake wrote:
Hello,
I ran into an interesting problem with a customer today. They are
running Jabber XCP (not the one we use). Unfortunately, the product
has a bug that causes it to leave connections persistent in a
transaction state. This is what it does:
BEGIN; SELECT 1;
Basica
On 3/30/07, Josh Berkus wrote:
I, personally, think that it's worth talking about integrating these.
However, the old versions were definitely NOT ready for integration, and the
new versions went on the internet like a week ago. Heck, I haven't even
downloaded them yet.
Yeah, the old version
41 matches
Mail list logo
