I'd like to propose support for IN and OUT parameters in 'DO' blocks.
Currently, anonymous code blocks (DO statements) can not receive or
return parameters.
I suggest:
1) Add a new clause to DO statement for specifying names, types,
directions and values of parameters:
DO code [LANGUAGE lang]
On 09/15/2014 08:56 PM, Robert Haas wrote:
On Mon, Sep 15, 2014 at 10:13 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
That makes for a bit awkward input and output from psql, when the values
used are 0, 1, 2, rather than ascii characters. But that's OK, because as
you said these
Hi
2014-09-16 8:38 GMT+02:00 Kalyanov Dmitry kalyanov.dmi...@gmail.com:
I'd like to propose support for IN and OUT parameters in 'DO' blocks.
Currently, anonymous code blocks (DO statements) can not receive or
return parameters.
I suggest:
1) Add a new clause to DO statement for
On Mon, Sep 15, 2014 at 11:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan p...@heroku.com writes:
On Mon, Sep 15, 2014 at 8:28 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
Rename such opclasses and make them not default.
Create new default opclasses with bitwise
On 09/16/2014 09:38 AM, Kalyanov Dmitry wrote:
I'd like to propose support for IN and OUT parameters in 'DO' blocks.
Currently, anonymous code blocks (DO statements) can not receive or
return parameters.
I suggest:
1) Add a new clause to DO statement for specifying names, types,
directions
2014-09-16 9:10 GMT+02:00 Heikki Linnakangas hlinnakan...@vmware.com:
On 09/16/2014 09:38 AM, Kalyanov Dmitry wrote:
I'd like to propose support for IN and OUT parameters in 'DO' blocks.
Currently, anonymous code blocks (DO statements) can not receive or
return parameters.
I suggest:
1)
On 09/16/2014 10:15 AM, Pavel Stehule wrote:
2014-09-16 9:10 GMT+02:00 Heikki Linnakangas hlinnakan...@vmware.com:
On 09/16/2014 09:38 AM, Kalyanov Dmitry wrote:
I'd like to propose support for IN and OUT parameters in 'DO' blocks.
Currently, anonymous code blocks (DO statements) can not
On 09/16/2014 09:15 AM, Pavel Stehule wrote:
2014-09-16 9:10 GMT+02:00 Heikki Linnakangas hlinnakan...@vmware.com
mailto:hlinnakan...@vmware.com:
On 09/16/2014 09:38 AM, Kalyanov Dmitry wrote:
I'd like to propose support for IN and OUT parameters in 'DO'
blocks.
No. And we don't know how to change the default opclass without
breaking things, either. See previous discussions about how we
might fix the totally-broken default gist opclass that btree_gist
creates for the inet type [1]. The motivation for getting rid of that
is *way* stronger than it
On Tue, Sep 16, 2014 at 11:29 AM, Emre Hasegeli e...@hasegeli.com wrote:
Changing the default opclasses should work if we make
pg_dump --binary-upgrade dump the default opclasses with indexes
and exclusion constraints. I think it makes sense to do so in
--binary-upgrade mode. I can try to
2014-09-16 9:24 GMT+02:00 Heikki Linnakangas hlinnakan...@vmware.com:
On 09/16/2014 10:15 AM, Pavel Stehule wrote:
2014-09-16 9:10 GMT+02:00 Heikki Linnakangas hlinnakan...@vmware.com:
On 09/16/2014 09:38 AM, Kalyanov Dmitry wrote:
I'd like to propose support for IN and OUT parameters in
On 09/16/2014 10:44 AM, Pavel Stehule wrote:
2014-09-16 9:24 GMT+02:00 Heikki Linnakangas hlinnakan...@vmware.com:
On 09/16/2014 10:15 AM, Pavel Stehule wrote:
Why we don't introduce a temporary functions instead?
You can already do that:
create function pg_temp.tempfunc(i int4) returns
On 09/16/2014 03:15 PM, Pavel Stehule wrote:
Why we don't introduce a temporary functions instead?
I think that'd be a lot cleaner and simpler. It's something I've
frequently wanted, and as Hekki points out it's already possible by
creating the function in pg_temp, there just isn't the syntax
On 09/16/2014 09:44 AM, Pavel Stehule wrote:
2014-09-16 9:24 GMT+02:00 Heikki Linnakangas hlinnakan...@vmware.com
mailto:hlinnakan...@vmware.com:
On 09/16/2014 10:15 AM, Pavel Stehule wrote:
2014-09-16 9:10 GMT+02:00 Heikki Linnakangas
hlinnakan...@vmware.com
2014-09-16 9:58 GMT+02:00 Heikki Linnakangas hlinnakan...@vmware.com:
On 09/16/2014 10:44 AM, Pavel Stehule wrote:
2014-09-16 9:24 GMT+02:00 Heikki Linnakangas hlinnakan...@vmware.com:
On 09/16/2014 10:15 AM, Pavel Stehule wrote:
Why we don't introduce a temporary functions instead?
(2014/08/15 6:18), Rukh Meski wrote:
Based on the feedback on my previous patch, I've separated only the
LIMIT part into its own feature. This version plays nicely with
inheritance. The intended use is splitting up big UPDATEs and DELETEs
into batches more easily and efficiently.
IIUC, the
2014-09-16 10:01 GMT+02:00 Hannu Krosing ha...@2ndquadrant.com:
On 09/16/2014 09:44 AM, Pavel Stehule wrote:
2014-09-16 9:24 GMT+02:00 Heikki Linnakangas hlinnakan...@vmware.com:
On 09/16/2014 10:15 AM, Pavel Stehule wrote:
2014-09-16 9:10 GMT+02:00 Heikki Linnakangas
On 09/16/2014 10:57 AM, Craig Ringer wrote:
On 09/16/2014 03:15 PM, Pavel Stehule wrote:
Why we don't introduce a temporary functions instead?
I think that'd be a lot cleaner and simpler. It's something I've
frequently wanted, and as Hekki points out it's already possible by
creating the
Changing the default opclasses should work if we make
pg_dump --binary-upgrade dump the default opclasses with indexes
and exclusion constraints. I think it makes sense to do so in
--binary-upgrade mode. I can try to come with a patch for this.
Can you explain it a bit more detail? I
2014-09-16 10:09 GMT+02:00 Heikki Linnakangas hlinnakan...@vmware.com:
On 09/16/2014 10:57 AM, Craig Ringer wrote:
On 09/16/2014 03:15 PM, Pavel Stehule wrote:
Why we don't introduce a temporary functions instead?
I think that'd be a lot cleaner and simpler. It's something I've
Hi,
On 2014-09-16 10:24:52 +0300, Heikki Linnakangas wrote:
On 09/16/2014 10:15 AM, Pavel Stehule wrote:
Why we don't introduce a temporary functions instead?
You can already do that:
create function pg_temp.tempfunc(i int4) returns int4 as $$ begin end; $$
language plpgsql;
It's quite
On Sat, Sep 13, 2014 at 1:33 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 09/12/2014 10:54 PM, Abhijit Menon-Sen wrote:
At 2014-09-12 22:38:01 +0300, hlinnakan...@vmware.com wrote:
We probably should consider switching to a faster CRC algorithm again,
regardless of what we do with
On Sat, Sep 13, 2014 at 1:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
On Fri, Sep 12, 2014 at 3:35 AM, Robert Haas robertmh...@gmail.com
wrote:
I haven't read the patch, but I think the question is why this needs
to be different than what we do for
On 2014-09-15 15:41:22 +0300, Heikki Linnakangas wrote:
Here we go. I've split this again into two patches. The first patch is just
refactoring the current code. It moves XLogInsert into a new file,
xloginsert.c, and the definition of XLogRecord to new xlogrecord.h header
file. As a result,
On 2014-09-16 15:43:06 +0530, Amit Kapila wrote:
On Sat, Sep 13, 2014 at 1:33 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 09/12/2014 10:54 PM, Abhijit Menon-Sen wrote:
At 2014-09-12 22:38:01 +0300, hlinnakan...@vmware.com wrote:
We probably should consider switching to a
On 09/16/2014 01:28 PM, Andres Freund wrote:
On 2014-09-16 15:43:06 +0530, Amit Kapila wrote:
On Sat, Sep 13, 2014 at 1:33 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 09/12/2014 10:54 PM, Abhijit Menon-Sen wrote:
At 2014-09-12 22:38:01 +0300, hlinnakan...@vmware.com wrote:
We
On 2014-09-16 13:49:20 +0300, Heikki Linnakangas wrote:
I used http://create.stephan-brumme.com/crc32/#slicing-by-8-overview as
reference - you can probably see the similarity. Any implementation is going
to look more or less the same, though; there aren't that many ways to write
the
Here is a patch to a bit improve the reference page for the LOCK
command. I think it'd be better for the isolation level to be in
capitals and wrapped in the literal tags.
Thanks,
Best regards,
Etsuro Fujita
diff --git a/doc/src/sgml/ref/lock.sgml b/doc/src/sgml/ref/lock.sgml
index
On Mon, Sep 15, 2014 at 8:38 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
The only reason why I put separate hooks here is,
create_custom_scan() needs to know exact size of the CustomScan
node (including private fields), however, it is helpful for
extensions to kick its callback to
On Mon, Sep 15, 2014 at 9:16 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
2) XLogCheckBufferNeedsBackup is not used. It can be removed.
Please ignore this comment, XLogCheckBufferNeedsBackup is used in heapam.c.
--
Michael
--
Sent via pgsql-hackers mailing list
On 2014-09-15 01:38:52 +0200, Petr Jelinek wrote:
- int64 minv, maxv, incby, bool is_cycled - these are basically options
giving info about how the new numbers are allocated (I guess some
implementations are not going to support all of those)
- bool is_called - the current built-in sequence
On Sun, Sep 14, 2014 at 12:23 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Fri, Sep 12, 2014 at 11:55 AM, Amit Chapel amit.kapil...@gmail.com
wrote:
On Thu, Sep 11, 2014 at 4:31 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-09-10 12:17:34 +0530, Amit Kapila wrote:
I will
On Tue, Sep 16, 2014 at 4:27 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-09-16 13:49:20 +0300, Heikki Linnakangas wrote:
I used http://create.stephan-brumme.com/crc32/#slicing-by-8-overview as
reference - you can probably see the similarity. Any implementation is
going
to look
On 17 February 2012 22:42, Jaime Casanova ja...@2ndquadrant.com wrote:
On Fri, Feb 17, 2012 at 4:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Has anybody stopped to look at the SQL standard for this? In-line
trigger definitions are actually what they intend, IIRC.
this is what i found
On Mon, Sep 15, 2014 at 3:00 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
At least a set of hooks has the merit to say: do what you like with
your synchronous node policy.
Sure. I dunno if people will find that terribly user-friendly, so we
might not want that to be the ONLY thing we
On 2014-09-16 13:15:59 +0100, Thom Brown wrote:
On 17 February 2012 22:42, Jaime Casanova ja...@2ndquadrant.com wrote:
On Fri, Feb 17, 2012 at 4:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Has anybody stopped to look at the SQL standard for this? In-line
trigger definitions are
On 16 September 2014 13:29, Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-16 13:15:59 +0100, Thom Brown wrote:
On 17 February 2012 22:42, Jaime Casanova ja...@2ndquadrant.com wrote:
On Fri, Feb 17, 2012 at 4:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Has anybody stopped to
On 2014-09-16 13:42:22 +0100, Thom Brown wrote:
The function can't be the target of CREATE OR REPLACE FUNCTION.
That *really* sucks. To the point of making the feature useless in my
eyes. That's really something frequently done.
Why not CREATE OR REPLACE TRIGGER? Wouldn't the
On 16 September 2014 13:45, Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-16 13:42:22 +0100, Thom Brown wrote:
The function can't be the target of CREATE OR REPLACE FUNCTION.
That *really* sucks. To the point of making the feature useless in my
eyes. That's really something
On 2014-09-16 13:54:49 +0100, Thom Brown wrote:
On 16 September 2014 13:45, Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-16 13:42:22 +0100, Thom Brown wrote:
The function can't be the target of CREATE OR REPLACE FUNCTION.
That *really* sucks. To the point of making the
On Mon, Sep 15, 2014 at 7:44 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus j...@agliodbs.com wrote:
Actually, having the keys all at the same level *is* relevant for the
issue we're discussing. If those 270 keys are organized in a tree, it's
not the
On Tue, Sep 16, 2014 at 12:14 PM, Emre Hasegeli e...@hasegeli.com wrote:
Changing the default opclasses should work if we make
pg_dump --binary-upgrade dump the default opclasses with indexes
and exclusion constraints. I think it makes sense to do so in
--binary-upgrade mode. I can
Etsuro Fujita fujita.ets...@lab.ntt.co.jp wrote:
(2014/08/15 6:18), Rukh Meski wrote:
Based on the feedback on my previous patch, I've separated only the
LIMIT part into its own feature. This version plays nicely with
inheritance. The intended use is splitting up big UPDATEs and DELETEs
On 09/16/2014 06:31 AM, Robert Haas wrote:
On Mon, Sep 15, 2014 at 7:44 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus j...@agliodbs.com wrote:
Actually, having the keys all at the same level *is* relevant for the
issue we're discussing. If those 270
On Tue, Sep 16, 2014 at 8:18 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
In most cases performance with patch is slightly less as compare
to HEAD and the difference is generally less than 1% and in a case
or 2 close to 2%. I think the main reason for slight difference is that
when the size
On Tue, Sep 16, 2014 at 12:47 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/16/2014 06:31 AM, Robert Haas wrote:
On Mon, Sep 15, 2014 at 7:44 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus j...@agliodbs.com wrote:
Actually, having the keys all at the
On Tue, Sep 16, 2014 at 11:31 AM, Kevin Grittner kgri...@ymail.com wrote:
Etsuro Fujita fujita.ets...@lab.ntt.co.jp wrote:
(2014/08/15 6:18), Rukh Meski wrote:
Based on the feedback on my previous patch, I've separated only the
LIMIT part into its own feature. This version plays nicely with
On 09/16/2014 09:54 AM, Robert Haas wrote:
On Tue, Sep 16, 2014 at 12:47 PM, Josh Berkus j...@agliodbs.com wrote:
On 09/16/2014 06:31 AM, Robert Haas wrote:
On Mon, Sep 15, 2014 at 7:44 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus j...@agliodbs.com
New version with semi join estimation function attached.
I have performed the following initial review:
- Patch format. -- submitted as unified, but not sure it makes it any
easier to read than context format.
- Apply to current master (77e65bf). -- success (though, I do get
Stripping
On 09/15/2014 11:12 AM, Tom Lane wrote:
Or are you proposing that JSONARRAY @ JSONARRAY should work differently
from ARRAY @ ARRAY?
And no. It's a bug that jsonb array containment works differently from
regular array containment. We understand the source of the bug, ie a
mistaken
I think there's been some changes to this patch since july, care to
resend a new version?
Sure, here it is.
The only difference with the previous version is that it now also
supports column defaults. This was found to be a problem when you drop
a sequence that some column default
On 09/16/2014 07:47 PM, Josh Berkus wrote:
On 09/16/2014 06:31 AM, Robert Haas wrote:
On Mon, Sep 15, 2014 at 7:44 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Sep 15, 2014 at 4:05 PM, Josh Berkus j...@agliodbs.com wrote:
Actually, having the keys all at the same level *is* relevant for
Hello everyone..i am new to PostgreSQL project. I had prior experience with
sql+ , with oracle 11g database server. Kindly help me grasp more about the
project or direct me in the right direction.
Thank you,
Tapan Halani
On Tue, Sep 16, 2014 at 5:25 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Sep 15, 2014 at 3:00 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
At least a set of hooks has the merit to say: do what you like with
your synchronous node policy.
Sure. I dunno if people will find
Hello,
Last month, I brought up the following issue to the general mailing list about
how running streaming replication between machines running different versions
of glibc can cause corrupt indexes.
http://www.postgresql.org/message-id/ba6132ed-1f6b-4a0b-ac22-81278f5ab...@tripadvisor.com
In
On Tue, Sep 16, 2014 at 3:12 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I'll leave it up to the jury to decide if we care or not. It seems like a
fairly unusual use case, where you push around large enough arrays or
objects to notice. Then again, I'm sure *someone* will do it. People
On Tue, Sep 16, 2014 at 1:11 PM, Josh Berkus j...@agliodbs.com wrote:
Well, I can only judge from the use cases I personally have, none of
which involve more than 100 keys at any level for most rows. So far
I've seen some people argue hypotetical use cases involving hundreds of
keys per
Heikki, Robert:
On 09/16/2014 11:12 AM, Heikki Linnakangas wrote:
Are you looking for someone with a real life scenario, or just synthetic
test case? The latter is easy to do.
See attached test program. It's basically the same I posted earlier.
Here are the results from my laptop with Tom's
On Tue, Sep 16, 2014 at 3:24 PM, Josh Berkus j...@agliodbs.com wrote:
Do you feel that way *as a code maintainer*? That is, if you ended up
maintaining the JSONB code, would you still feel that it's worth the
extra complexity? Because that will be the main cost here.
I feel that Heikki
On 16/09/14 21:20, Robert Haas wrote:
In practice, I'm not very surprised that the impact doesn't seem too
bad when you're running SQL queries from the client. There's so much
other overhead, for de-TOASTing and client communication and even just
planner and executor costs, that this gets lost
Hi,
I am new to PostGre SQL and want to ask some questions. In my database
class, we plan to work on a class project based on WAL. Since we are not
familiar with WAL, we don't know what's a good start point. Could anyone
point me to any documentation mentioning about WAL in PostGre SQL? It will
Hi,
I've been working a little bit on a patch for printing tables in asciidoc
with psql.
It's not finished yet, I'm not sure it there is any sense in supporting
border types etc. The code is not cleared so far, but any remarks on the
style not playing well with the normal postgres style of code
On 09/16/2014 10:37 PM, Robert Haas wrote:
On Tue, Sep 16, 2014 at 3:24 PM, Josh Berkus j...@agliodbs.com wrote:
Do you feel that way *as a code maintainer*? That is, if you ended up
maintaining the JSONB code, would you still feel that it's worth the
extra complexity? Because that will be
On 09/16/2014 10:50 PM, Mingzhe Li wrote:
Hi,
I am new to PostGre SQL and want to ask some questions. In my database
class, we plan to work on a class project based on WAL. Since we are not
familiar with WAL, we don't know what's a good start point. Could anyone
point me to any documentation
On Tue, Sep 16, 2014 at 4:20 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Sep 16, 2014 at 1:11 PM, Josh Berkus j...@agliodbs.com wrote:
Well, I can only judge from the use cases I personally have, none of
which involve more than 100 keys at any level for most rows. So far
I've
On Mon, Sep 15, 2014 at 7:21 PM, Peter Geoghegan p...@heroku.com wrote:
On Mon, Sep 15, 2014 at 11:25 AM, Peter Geoghegan p...@heroku.com wrote:
OK, I'll draft a patch for that today, including similar alterations
to varstr_cmp() for the benefit of Windows and so on.
I attach a much simpler
On Tue, Sep 16, 2014 at 1:45 PM, Robert Haas robertmh...@gmail.com wrote:
Even though our testing seems to indicate that the memcmp() is
basically free, I think it would be good to make the effort to avoid
doing memcmp() and then strcoll() and then strncmp(). Seems like it
shouldn't be too
On 16/09/14 14:17, Andres Freund wrote:
On 2014-09-15 01:38:52 +0200, Petr Jelinek wrote:
There is also more needed than this, you need:
- int64 value - first value allocated (value to be returned)
- int64 nvalues - number of values allocated
- int64 last - last cached value (used for
On 9/16/14 12:06 PM, Matthew Kelly wrote:
The second and far more challenging problem is how do we fix this issue?
As of our last discussion, Peter Geoghegan revived the proposal of
using ICU as an alternative.
On 04/09/14 18:02, Craig Ringer wrote:
On 09/04/2014 06:48 AM, Joshua D. Drake wrote:
On 09/03/2014 11:48 AM, Robert Haas wrote:
Anyway, to get back around to the topic of PL/SQL compatibility
specifically, if you care about that issue, pick one thing that exists
in PL/SQL but not in
On 03/09/14 20:48, Robert Haas wrote:
On Tue, Sep 2, 2014 at 5:47 PM, Álvaro Hernández Tortosa a...@nosys.es wrote:
Yeah, we differ there. I think having an Oracle compatibility layer in
PostgreSQL would be the-next-big-thing we could have. Oracle is has orders
of magnitude bigger user
On Tue, Sep 16, 2014 at 2:07 PM, Peter Eisentraut pete...@gmx.net wrote:
Clearly, this is worth documenting, but I don't think we can completely
prevent the problem. There has been talk of a built-in index integrity
checking tool. That would be quite useful.
We could at least use the GNU
On Tue, Sep 16, 2014 at 2:07 PM, Peter Eisentraut pete...@gmx.net wrote:
It seems to me that this is a more general problem that can affect any
data type that relies on anything external. For example, you could
probably create a case where indexes are corrupted if you have two
different time
- Цитат от Robert Haas (robertmh...@gmail.com), на 16.09.2014 в 22:20 -
In practice, I'm not very surprised that the impact doesn't seem too
bad when you're running SQL queries from the client. There's so much
other overhead, for de-TOASTing and client communication and even just
On 09/17/2014 02:16 AM, Tapan Halani wrote:
Hello everyone..i am new to PostgreSQL project. I had prior experience
with sql+ , with oracle 11g database server. Kindly help me grasp more
about the project or direct me in the right direction.
I've replied off-list to direct the poster to some
On 09/17/2014 03:50 AM, Mingzhe Li wrote:
Hi,
I am new to PostGre SQL and want to ask some questions. In my database
class, we plan to work on a class project based on WAL. Since we are not
familiar with WAL, we don't know what's a good start point. Could anyone
point me to any
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 09/16/2014 10:37 PM, Robert Haas wrote:
On Tue, Sep 16, 2014 at 3:24 PM, Josh Berkus j...@agliodbs.com wrote:
Do you feel that way *as a code maintainer*? That is, if you ended up
maintaining the JSONB code, would you still feel that it's
77 matches
Mail list logo
