There are now two branches of MERGE code in review progress available.
http://github.com/greg2ndQuadrant/postgres/tree/merge-unstable has the
bit-rotted version that doesn't quite work against HEAD yet, while
http://github.com/greg2ndQuadrant/postgres/tree/merge is what I'm still
testing again
Robert Haas writes:
> Ooh, I like it. A related personal pet peeve of mine: AFAIK the
> easiest way to convert from an integer number of seconds to an
> interval representing that many seconds is:
> (the_int || ' s')::interval
No, the standard solution is
the_int * '1 second'::interval
Dimitri Fontaine writes:
> Anyway, my point is that by default there's no directory scanning: the
> lookup is first directed towards ${extension-name}.control, of
> course. Only when this file does not exists or its name property is
> different from the extension name do we get to scan the directo
On Fri, Oct 22, 2010 at 4:27 PM, Alvaro Herrera
wrote:
> Excerpts from Alvaro Herrera's message of vie oct 22 17:13:31 -0300 2010:
>> Excerpts from Robert Haas's message of vie oct 22 16:54:01 -0300 2010:
>>
>> > Ooh, I like it. A related personal pet peeve of mine: AFAIK the
>> > easiest way to
Excerpts from Alvaro Herrera's message of vie oct 22 17:13:31 -0300 2010:
> Excerpts from Robert Haas's message of vie oct 22 16:54:01 -0300 2010:
>
> > Ooh, I like it. A related personal pet peeve of mine: AFAIK the
> > easiest way to convert from an integer number of seconds to an
> > interval
> Yeah - what is the feasibility of cleaning up the things where there
> are naming inconsistencies right now?
Easy. Heck, the only reason we didn't do it 2 years ago was that we
were waiting for extensions before bothering.
Go Dimitri! Yaaay.
--
-- Josh Ber
Excerpts from Robert Haas's message of vie oct 22 16:54:01 -0300 2010:
> Ooh, I like it. A related personal pet peeve of mine: AFAIK the
> easiest way to convert from an integer number of seconds to an
> interval representing that many seconds is:
>
> (the_int || ' s')::interval
>
> I guess we
Excerpts from Robert Haas's message of vie oct 22 17:07:10 -0300 2010:
> On Fri, Oct 22, 2010 at 4:02 PM, Alvaro Herrera
> wrote:
> > That said, I don't think there's any reason now to stop a committer from
> > renaming files (as long as this has been previously discussed and agreed
> > to, just l
On Fri, Oct 22, 2010 at 4:02 PM, Alvaro Herrera
wrote:
> That said, I don't think there's any reason now to stop a committer from
> renaming files (as long as this has been previously discussed and agreed
> to, just like any other commit).
Yeah - what is the feasibility of cleaning up the things
Excerpts from Dimitri Fontaine's message of vie oct 22 16:21:14 -0300 2010:
> So I think it's a good compromise, and as it's superuser-only I would
> think it's acceptable as-is. Apparently it's not, which ain't the end of
> the world but an unexpected surprise for me. And when I don't
> understan
On Fri, Oct 22, 2010 at 3:20 PM, Brendan Jurd wrote:
> On 23 October 2010 06:15, Josh Berkus wrote:
>> a) you'd need to rename these.
>
> I'm open to that. What names would you propose?
>
>> b) we'd also want the inverse of these, which would be extremely useful.
>
> Not a problem.
Ooh, I like
Dimitri Fontaine writes:
> For information, when we talk about performance problem, please note
> that on my workstation with a default setup (not that it's important
> here) we're talking about 86,420 ms for a loop of 100
> perform * from pg_extensions;
That's right, but
> That displays 36 ex
Alvaro Herrera writes:
> Well, things like pgfoundry project names are also restricted AFAICT and
> I don't think anyone has a problem with that.
For things you publish, sure. But extensions will also handle in-house
developments of functions and other in-database API-like stuff, in fact
any SQL
On 23 October 2010 06:15, Josh Berkus wrote:
> a) you'd need to rename these.
I'm open to that. What names would you propose?
> b) we'd also want the inverse of these, which would be extremely useful.
Not a problem.
Cheers,
BJ
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
Brendan,
> date(year int, month int, day int) returns date
> datetime(year int, month int, day int, hour int, minute int, second
> int) returns timestamp
a) you'd need to rename these.
b) we'd also want the inverse of these, which would be extremely useful.
> Without these functions (or some var
On 23 October 2010 05:58, Peter Geoghegan wrote:
> On 22 October 2010 19:45, Brendan Jurd wrote:
>> Without these functions (or some variation), a user wishing to
>> construct a date from integers can only assemble the date into a
>> string and then put that string through postgres' datetime pars
On Fri, Oct 22, 2010 at 2:45 PM, Brendan Jurd wrote:
> date(year int, month int, day int) returns date
> datetime(year int, month int, day int, hour int, minute int, second
> int) returns timestamp
>
> Without these functions (or some variation), a user wishing to
> construct a date from integers
Hello guys,
I'm writing a function that will read data from the buffer in xlog (i.e.
from XLogCtl->pages and XLogCtl->xlblocks). I want to make sure that I am
doing it correctly.
For reading from the buffer, do I need to lock WALInsertLock or
WALWriteLock? Also, can you explain a bit the usage of
On 22 October 2010 19:45, Brendan Jurd wrote:
> Hi folks,
>
> In my own databases, I've been using a couple of C functions that
> might be useful to the wider community.
>
> They are very simple date/timestamp constructors that take integers as
> their arguments. Nothing fancy, but very convenien
Hi folks,
In my own databases, I've been using a couple of C functions that
might be useful to the wider community.
They are very simple date/timestamp constructors that take integers as
their arguments. Nothing fancy, but very convenient and *much* faster
than using a SQL or PL/pgSQL workaround
Excerpts from Dimitri Fontaine's message of vie oct 22 13:30:22 -0300 2010:
> So extension names are forced into English? I would live with that, I
> just don't find the answer friendly to the users.
Well, things like pgfoundry project names are also restricted AFAICT and
I don't think anyone has
On Fri, Oct 22, 2010 at 02:02:48PM +0100, Leonardo Francalanci wrote:
> Hi,
>
> I want to write a custom agg function that, given an "int4 index",
> increments the element at "index" of an array and, at the end,
> returns the array. The array will always be int4[].
Before you start coding, have
max_wal_size
min_wal_size
[ scratches head... ] What's the functional effect of min_wal_size, exactly?
Replaces wal_keep_segments. The rename is to make the GUCs obviously
symmetrical, and to make it clear that the *meaning* of the variable has
changed.
Even better would be to replace
Josh Berkus writes:
> What would be sensible for DBAs is to have two settings:
> max_wal_size
> min_wal_size
[ scratches head... ] What's the functional effect of min_wal_size, exactly?
> Even better would be to replace min_wal_size with min_wal_time, which
> would set a time span for the old
2010/10/22 Teodor Sigaev
> Type should have in/out function, at least dummy. If type is not present in
> pg_type table then postgres can not operate with even on disk.
>
Yes, you are right. I did some tests and I found that in order for it to
work correctly the type we specify in STORAGE paramet
Please see
http://archives.postgresql.org/pgsql-docs/2010-10/msg00038.php
Ye gods and little fishes!
You really want to talk arcane formulas. I've re-read that
three times, and am still not sure that I could tell someone
definitively how much disk space WAL needs for a given group of
setti
Andrew Dunstan writes:
> ASCII is not the same thing as English. You can create the names in Pig
> Latin or Redneck if you want. It's the charset that's being restricted here,
> and we restrict many more things than this to ASCII.
I'd like to read Itagaki's opinion here, will wait :)
--
Dimitri
On Oct 19, 2010, at 2:01 PM, Martijn van Oosterhout wrote:
> On Tue, Oct 19, 2010 at 02:52:01PM -0400, Robert Haas wrote:
>> Well, temp tables really want a separate set of XIDs with a separate
>> CLOG, too. Admittedly, they don't necessarily need WAL, if you can
>> make them work without catalog
On 10/22/2010 12:30 PM, Dimitri Fontaine wrote:
Alvaro Herrera writes:
Excerpts from Dimitri Fontaine's message of vie oct 22 12:25:07 -0300 2010:
Now, if we want to do it the other way round and force extension name to
be the filename, we will have to live with all the restrictions that
fi
Alvaro Herrera writes:
> Excerpts from Dimitri Fontaine's message of vie oct 22 12:25:07 -0300 2010:
>
>> Now, if we want to do it the other way round and force extension name to
>> be the filename, we will have to live with all the restrictions that
>> filename imposes and that are not the same d
Excerpts from Alvaro Herrera's message of vie oct 22 13:17:41 -0300 2010:
> > Given that the control file now supports an encoding parameter, I don't
> > see what this is good for, but I might be missing something obvious for
> > people working with different encodings etc. Japan seems to be quite
Excerpts from Dimitri Fontaine's message of vie oct 22 12:25:07 -0300 2010:
> Now, if we want to do it the other way round and force extension name to
> be the filename, we will have to live with all the restrictions that
> filename imposes and that are not the same depending on the OS and the
> f
On 10/21/2010 08:36 PM, Greg Smith wrote:
Robert Haas wrote:
I think the right way to write UPSERT is something
along the lines of:
MERGE INTO Stock t USING (VALUES (10, 1)) s(item_id, balance) ON
s.item_id = t.item_id ...
[...]
Here's what the query plan looks like on a MATCH:
Merge (cost
Tom Lane writes:
> Yes. It's horrid for performance, and it's worse for understandability,
> and there's no obvious benefit to set against those. Please let's make
> the rule that the control file name equals the extension name.
Performance… well if you say that CREATE EXTENSION performance pre
Alvaro Herrera writes:
>> Fixed by having the CREATE EXTENSION command consider it's being given
>> the name of the extension as found in the control file, rather than the
>> control file base name.
>
> Hang on. Did I miss something? Why doesn't the control file name equal
> the extension name?
Heikki Linnakangas writes:
> On 22.10.2010 06:10, Tom Lane wrote:
>> (But on the third
>> hand, what are we gonna do for back-patching to versions without the
>> plancache?)
> One simple idea is to keep a flag along with the executor state to
> indicate that the executor state is currently in us
On 22.10.2010 16:54, Tom Lane wrote:
Heikki Linnakangas writes:
OFF is a reserved keyword. It's not a reserved keyword in the SQL spec,
and it's not hard to see people using off as a variable or column name,
so it would be nice to relax that.
While I can see the value of doing something about
Alvaro Herrera writes:
> Hang on. Did I miss something? Why doesn't the control file name equal
> the extension name? I think the idea that you have to scan the whole
> share directory and parse all control files to find the one you need is
> a bit strange.
Yes. It's horrid for performance, a
Excerpts from Dimitri Fontaine's message of vie oct 22 10:43:58 -0300 2010:
> Itagaki Takahiro writes:
> > * There are some inconsistency between extension names in \dx+ view
> > and actual name used by CREATE EXTENSION.
> > - auto_username => insert_username
> > - intarray => _int
> > - xm
Itagaki Takahiro writes:
> BTW, did you register your patch to the next commitfest?
> It would be better to do so for tracking the activities.
> https://commitfest.postgresql.org/action/commitfest_view?id=8
https://commitfest.postgresql.org/action/patch_view?id=404
--
Dimitri Fontaine
http://2n
Heikki Linnakangas writes:
> OFF is a reserved keyword. It's not a reserved keyword in the SQL spec,
> and it's not hard to see people using off as a variable or column name,
> so it would be nice to relax that.
While I can see the value of doing something about that, this seems
awfully fragile
Hi,
I want to write a custom agg function that, given an "int4 index",
increments the element at "index" of an array and, at the end, returns
the array. The array will always be int4[].
I need it in C, since plpgsql is way slower (and I need to use it in
5M+ rows). I did it, but I also need to c
You can define the additional argument as providing all of the extra
info about how the operator is being used, and, if it's being used for
ordering, the details of the requested order. What is your thinking
on the matter?
Maby be useful, but it seems to me to be a bit overengineering for now.
Are you refering to table pg_type?
If yes, those type structures exist only in c I didn't write any in-out
functions, so they don't exist in sql level.
Type should have in/out function, at least dummy. If type is not present in
pg_type table then postgres can not operate with even on disk.
--
Dimitri Fontaine writes:
> That's done now and for those paying attention, of course those examples
> won't need to add a script property in their control files, as soon as
> we both scan the SHAREDIR to find the proper control file and that the
> default script is ${name}.sql, which is what's use
Dimitri Fontaine writes:
> I lean toward adding support for a script variable into the control file
> which defaults to script = '${name}.sql' and will have to be edited only
> in those 3 cases you're reporting about. I'm going to work on that this
> morning, it looks simple enough to get reworked
Hello
I reworked a implementation of format function. This respects last discussion:
* support a positional placeholders - syntax %99$x,
* support a tags: %s, I, L,
* enhanced documentation,
* enhanced reggress tests
Regards
Pavel Stehule
*** ./doc/src/sgml/func.sgml.orig 2010-10-21 14:40:44.00
OFF is a reserved keyword. It's not a reserved keyword in the SQL spec,
and it's not hard to see people using off as a variable or column name,
so it would be nice to relax that. To make things worse, OFFSET is also
a reserved keyword, which would be the other natural name for a variable
or col
48 matches
Mail list logo
