Alvaro Herrera writes:
> Are we going to add pg_pltemplate entries for external PLs for 8.4?
> I mean new rows for PL/pgPSM, PL/LOLCODE, PL/php, that sort of stuff.
> I think we should. In fact AFAIR we said we were going to, back when
> this catalog was invented.
That was part of the origina
Hi,
Are we going to add pg_pltemplate entries for external PLs for 8.4?
I mean new rows for PL/pgPSM, PL/LOLCODE, PL/php, that sort of stuff.
I think we should. In fact AFAIR we said we were going to, back when
this catalog was invented.
This seems like a good time. Thoughts?
--
Alvaro Her
Tom Lane wrote:
> Peter Eisentraut writes:
> > ... Moreover, there does not actually seem to be a
> > way to find out whether you have a 32-bit or a 64-bit build (except by
> > using OS tools).
>
> I think the basic definition of "32 bit" or "64 bit", certainly for
> our purposes, is sizeof(vo
"Robert Haas" writes:
>> Apparently that analogy didn't impress anyone but me.
> It impressed me. I liked making WINDOW a flag that occurs later in
> the statement a lot better.
I ended up going with the flag/attribute approach. The other would be
only marginally more work now, but I remain co
On Tue, Dec 30, 2008 at 04:07:33PM -0500, Jaime Casanova wrote:
> On Tue, Dec 30, 2008 at 2:00 PM, David Fetter wrote:
> > Here's one such use-case. Let's say a table has gotten large and
> > you've decided to partition it. You add child tables, add one or
> > more triggers to the parent table t
>>> Heikki Linnakangas wrote:
> If you have a concrete suggestion (= patch) for the documentation,
I'm
> all ears.
I'm still working on section "Serializable Isolation versus True
Serializability", but here are all the changes I can see which precede
it. Has the review of the SQL specs convin
On Tue, Dec 30, 2008 at 2:00 PM, David Fetter wrote:
>
> Here's one such use-case. Let's say a table has gotten large and
> you've decided to partition it. You add child tables, add one or more
> triggers to the parent table to make sure it never gets a row,
> populate the child tables from the
No docs or regression tests yet, but it seems to work ... please check
against Oracle and DB2 behavior. Supported cases are
RANGE UNBOUNDED PRECEDING -- same as AND CURRENT ROW
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
RANGE BETWEEN UNBOUNDED PRECEDING AND UN
Now we are moving closer to 8.4, please join us for testing 8.4 release.
I just released new RPM sets, which is based on Dec 29 2008 CVS
snapshot, which includes Window Functions patch. Please note that these
packages are **not** production ready. They are for Fedora 9 and
RHEL/CentOS 5. I have n
David Fetter writes:
> Presumably psql should know about this change. Should \df now include
> windowing functions along with a boolean column that indicates whether
> a function is a windowing function? Should there be \dw[+] instead?
> In either case, should the S option indicating "include s
David Fetter wrote:
> > My vote is to just go ahead and change it. I don't really see much
> > of a use-case for truncating only the parent of an inheritance
> > hierarchy anyway, so I doubt that many people would be affected.
>
> Here's one such use-case. Let's say a table has gotten large and
On Tue, Dec 30, 2008 at 11:50:06AM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Peter Eisentraut wrote:
> >> Considering that TRUNCATE is a pretty dangerous operation, how can we
> >> make adjustments to the behavior without upsetting lots of users?
>
> > Well, it is one of those, "Either
> Apparently that analogy didn't impress anyone but me. AFAICT the
> majority opinion is that we should use the syntax
>
>create [or replace] [window] function ...
>
> but just ignore the distinction between regular functions and window
> functions for all other function-related SQL comman
On Tue, Dec 30, 2008 at 11:59:22AM -0500, Tom Lane wrote:
> I wrote:
> > You could certainly argue the classification either way, but I
> > think that we should make a hard decision now: either window
> > functions are treated as a distinct object type (implying their
> > own set of command names a
>>> "Robert Haas" wrote:
>> The effects are different, I think, in that there isn't a
>> serialization failure in some conflict cases where you would get
one
>> with actual updates. I found a paper on how to use updates to
provide
>> serializable transactions in a snapshot database, and I'd hav
Bruce Momjian writes:
> Tom Lane wrote:
>> My vote is to just go ahead and change it. I don't really see much
>> of a use-case for truncating only the parent of an inheritance
>> hierarchy anyway, so I doubt that many people would be affected.
agreed.
>> I note though that we have a lot of oth
>>> Peter Eisentraut wrote:
> Greg Stark wrote:
>> And I don't see why you discard "visibility" as unimportant. All
>> the transaction isolations are defined in terms of the results if
>> the transactions. Those results include both the database state and
>> the data returned by the queries. Othe
Tom Lane wrote:
> Bruce Momjian writes:
> > Peter Eisentraut wrote:
> >> Considering that TRUNCATE is a pretty dangerous operation, how can we
> >> make adjustments to the behavior without upsetting lots of users?
>
> > Well, it is one of those, "Either we fix it or live with the
> > inconsisten
I wrote:
> You could certainly argue the classification either way, but I think
> that we should make a hard decision now: either window functions are
> treated as a distinct object type (implying their own set of command
> names and nuisance errors if you use the wrong one), or they are not a
> di
On Mon, Dec 29, 2008 at 15:46, Alex Hunsaker wrote:
> On Thu, Dec 25, 2008 at 23:04, ITAGAKI Takahiro
> wrote:
>> Here is an updated version of contrib/pg_stat_statements patch.
>
> Im going to do some more testing, give the typedef Chunk stuff another
> look (you did fix the race/not protected b
Bruce Momjian writes:
> Peter Eisentraut wrote:
>> Considering that TRUNCATE is a pretty dangerous operation, how can we
>> make adjustments to the behavior without upsetting lots of users?
> Well, it is one of those, "Either we fix it or live with the
> inconsistency forever". Historically we
Simon Riggs wrote:
(a) always ignore LP_DEAD flags we see when reading index during
recovery.
This sounds simplest, and it's nice to not clear the flags for the
benefit of transactions running after the recovery is done.
You have to be careful to ignore the flags in read-only transactions
t
Simon Riggs wrote:
nbtree.h refers to LP_DELETEd tuples on line 75, but that state is now
referred to as LP_DEAD in itemid.h, so the comment makes no obvious
sense.
Fixed.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Peter Eisentraut wrote:
> Peter Eisentraut wrote:
> > On Monday 22 December 2008 05:09:54 Jaime Casanova wrote:
> >> just out of curiosity, why TRUNCATE doesn't support ONLY?
> >
> > It was probably just an omission.
> >
> > Note that TRUNCATE currently does not act on inheriting tables. In othe
On Mon, 2008-12-29 at 13:02 +0200, Heikki Linnakangas wrote:
> >> That will ensure that the standby doesn't need to stall WAL
> >> application because of read-only queries.
> >
> > It doesn't need to. That is already optional.
>
> Oh right. I should've added, "without having to kill queries".
> The effects are different, I think, in that there isn't a
> serialization failure in some conflict cases where you would get one
> with actual updates. I found a paper on how to use updates to provide
> serializable transactions in a snapshot database, and I'd have to
> review closely to see how
>>> "Robert Haas" wrote:
> On Mon, Dec 29, 2008 at 9:28 PM, Gregory Stark
wrote:
>> "Kevin Grittner" writes:
>>> (3) A finer-grained approach would be to make no-effect updates
to
>>> rows to lock them if they are to be read for purposes of updating
>>> something else in the transaction. This
Peter Eisentraut writes:
> ... Moreover, there does not actually seem to be a
> way to find out whether you have a 32-bit or a 64-bit build (except by
> using OS tools).
I think the basic definition of "32 bit" or "64 bit", certainly for
our purposes, is sizeof(void *). That is something that
Alvaro Herrera wrote:
> Tom Lane wrote:
> > Alvaro Herrera writes:
>
> > > I'm intending to have a new routine which would reserve a value at
> > > runtime. This value would be later be passed by the AM to create new
> > > options on the table.
> >
> > What do you mean by "at runtime"? Surely
Simon Riggs wrote:
Issues (2) and (3) would go away entirely if both standby and primary
always had the same xmin value as a system-wide setting. i.e. the
standby and primary are locked together at their xmins. Perhaps that was
Heikki's intention in recent suggestions?
No, I only suggested tha
On Fri, 2008-12-19 at 09:22 -0500, Greg Stark wrote:
> I'm confused shouldn't read-only transactions on the slave just be
> hacked to not set any hint bits including lp_delete?
It seems there are multiple issues involved and I saw only the first of
these initially. I want to explicitly separat
nbtree.h refers to LP_DELETEd tuples on line 75, but that state is now
referred to as LP_DEAD in itemid.h, so the comment makes no obvious
sense.
It would seem worth documenting the name change, so that old mailing
list stuff makes sense.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQ
On Tue, 2008-12-30 at 14:40 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> >
> > That for me is beginning to sound fairly ugly: difficult to understand
> > and difficult to use. But I see some people might want that in certain
> > circumstances. So I guess we should build it. Any good id
Simon Riggs wrote:
The difficulty is arriving at an easy-to-use control mechanism that is
also secure.
The options for handling a conflict are these:
1. Ignore the conflict (and allow silent wrong answers)
2. Allow the conflicting query to progress until it sees changed data
3. Cancel the query
Robert Haas wrote:
Currently, use of window functions always forces sorting, ...
That's not strictly true, actually. No sort is done if the input happens
to be sorted already, as in:
postgres=# CREATE TABLE foo (id integer PRIMARY KEY);
NOTICE: CREATE TABLE / PRIMARY KEY will create implici
On Mon, 2008-12-29 at 13:02 +0200, Heikki Linnakangas wrote:
> I haven't seen any one-size-fits-all solution to this issue, so we
> have to cater for many.
Very much agree. I've had the chance to speak to many people about the
way they would like this to work and there is definitely no consensu
Here is the next patch version.
The naming and style concerns have been addressed. The patch now only
touches 5 files. 4 of those files are hashjoin specific and 1 is to
add a couple lines to a hashjoin specific struct in another file.
The code can now find the the MCVs in more cases. Even if
Peter Eisentraut wrote:
On Monday 22 December 2008 05:09:54 Jaime Casanova wrote:
just out of curiosity, why TRUNCATE doesn't support ONLY?
It was probably just an omission.
Note that TRUNCATE currently does not act on inheriting tables. In other
words, the behavior is already like ONLY.
Greg Stark wrote:
And I don't see why you discard "visibility" as unimportant. All the
transaction isolations are defined in terms of the results if the
transactions. Those results include both the database state and the data
returned by the queries. Otherwise "phantom read" is a meaningless co
It has been pointed out to me that the output of the version() function
is becoming more confusing in face of mixed 32/64 bit environments.
Output like i486-pc-linux-gnu just says what kind of kernel the build
environment has, not whether you actually have a IA-32 build.
Conversely, amd64-pc-li
40 matches
Mail list logo
