Hi,
On Jun 19, 2011, at 2:10 PM, Noah Misch wrote:
On Sat, Jun 18, 2011 at 11:32:20PM -0400, Robert Haas wrote:
On Sat, Jun 18, 2011 at 11:12 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jun 18, 2011 at 11:06 PM, Noah Misch n...@leadboat.com wrote:
On Sat, Jun 18, 2011 at 10:57:13PM
On Tue, Jun 21, 2011 at 06:31:44PM +0300, Alexey Klyukin wrote:
Here is my review of this patch.
Thanks!
The patch applies cleanly to the HEAD, produces no additional warnings. It
doesn't include additional regression tests. One can include a test, using the
commands like the ones included
On Jun 21, 2011, at 9:58 PM, Noah Misch wrote:
A pg_regress test needs stable output, so we would do it roughly like this:
CREATE TEMP TABLE relstorage AS SELECT 0::regclass AS oldnode;
...
UPDATE relstorage SET oldnode =
(SELECT relfilenode FROM pg_class
On Tue, Jun 21, 2011 at 5:50 PM, Alexey Klyukin al...@commandprompt.com wrote:
On Jun 21, 2011, at 9:58 PM, Noah Misch wrote:
A pg_regress test needs stable output, so we would do it roughly like this:
CREATE TEMP TABLE relstorage AS SELECT 0::regclass AS oldnode;
...
On Sat, Jun 18, 2011 at 11:32:20PM -0400, Robert Haas wrote:
On Sat, Jun 18, 2011 at 11:12 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jun 18, 2011 at 11:06 PM, Noah Misch n...@leadboat.com wrote:
On Sat, Jun 18, 2011 at 10:57:13PM -0400, Robert Haas wrote:
On Sat, Jun 11, 2011 at
On Sat, Jun 11, 2011 at 5:13 PM, Noah Misch n...@leadboat.com wrote:
Sounds good. Updated patch attached, incorporating your ideas. Before
applying
it, run this command to update the uninvolved pg_proc.h DATA entries:
perl -pi -e 's/PGUID(\s+\d+){4}/$ 0/' src/include/catalog/pg_proc.h
On Sat, Jun 18, 2011 at 10:57:13PM -0400, Robert Haas wrote:
On Sat, Jun 11, 2011 at 5:13 PM, Noah Misch n...@leadboat.com wrote:
Sounds good. ?Updated patch attached, incorporating your ideas. ?Before
applying
it, run this command to update the uninvolved pg_proc.h DATA entries:
?perl
On Sat, Jun 18, 2011 at 11:06 PM, Noah Misch n...@leadboat.com wrote:
On Sat, Jun 18, 2011 at 10:57:13PM -0400, Robert Haas wrote:
On Sat, Jun 11, 2011 at 5:13 PM, Noah Misch n...@leadboat.com wrote:
Sounds good. ?Updated patch attached, incorporating your ideas. ?Before
applying
it, run
On Sat, Jun 18, 2011 at 11:12 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Jun 18, 2011 at 11:06 PM, Noah Misch n...@leadboat.com wrote:
On Sat, Jun 18, 2011 at 10:57:13PM -0400, Robert Haas wrote:
On Sat, Jun 11, 2011 at 5:13 PM, Noah Misch n...@leadboat.com wrote:
Sounds good.
Noah Misch n...@leadboat.com writes:
We originally discussed having the transform function take and return Expr
nodes. It turns out that simplify_function() does not have the Expr, probably
because the particular choice of node type among the many that can convey a
function call does not
On Sat, Jun 11, 2011 at 02:11:55PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
We originally discussed having the transform function take and return Expr
nodes. It turns out that simplify_function() does not have the Expr,
probably
because the particular choice of node
Noah Misch n...@leadboat.com writes:
Good points. I'm thinking, then, add an Expr argument to simplify_function()
and have the CoerceViaIO branch of eval_const_expressions_mutator() pass NULL
for both its simplify_function() calls. If simplify_function() gets a NULL
Expr
for a function
On Sat, Jun 11, 2011 at 03:03:18PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
Good points. I'm thinking, then, add an Expr argument to
simplify_function()
and have the CoerceViaIO branch of eval_const_expressions_mutator() pass
NULL
for both its simplify_function()
Hi,
On Jun 2, 2011, at 10:22 PM, Noah Misch wrote:
Hi Alexey,
...
Is your interest in cheap varchar(N)-varchar(N+M) conversions specifically,
or
in some broader application of this facility?
Exactly varchar conversions.
Thanks for volunteering to review; that will be a big help.
On Jun 3, 2011, at 10:11 AM, Alexey Klyukin wrote:
Is your interest in cheap varchar(N)-varchar(N+M) conversions specifically,
or
in some broader application of this facility?
Exactly varchar conversions.
Why limit it to varchar? Shouldn't we be able to do this for any varlena? The
only
Jim Nasby j...@nasby.net wrote:
The only challenge I see is numeric; we'd need to ensure that both
size and precision are not decreasing.
To be picky, wouldn't that need to be neither (precision - scale)
nor scale is decreasing?
-Kevin
--
Sent via pgsql-hackers mailing list
On Fri, Jun 3, 2011 at 11:43 AM, Jim Nasby j...@nasby.net wrote:
On Jun 3, 2011, at 10:11 AM, Alexey Klyukin wrote:
Is your interest in cheap varchar(N)-varchar(N+M) conversions
specifically, or
in some broader application of this facility?
Exactly varchar conversions.
Why limit it to
On Fri, Jun 03, 2011 at 10:43:17AM -0500, Jim Nasby wrote:
On Jun 3, 2011, at 10:11 AM, Alexey Klyukin wrote:
Is your interest in cheap varchar(N)-varchar(N+M) conversions
specifically, or
in some broader application of this facility?
Exactly varchar conversions.
Why limit it to
On May 24, 2011, at 12:15 AM, Noah Misch wrote:
On Mon, May 23, 2011 at 03:01:40PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
Good deal. Given that conclusion, the other policy decision I anticipate
affecting this particular patch is the choice of syntax. Presumably, it
Hi Alexey,
On Thu, Jun 02, 2011 at 05:08:51PM +0300, Alexey Klyukin wrote:
Looks like this thread has silently died out. Is there an agreement on the
syntax and implementation part? We (CMD) have a customer, who is interested in
pushing this through, so, if we have a patch, I'd be happy to
On Mon, May 23, 2011 at 12:42 PM, Noah Misch n...@leadboat.com wrote:
I'd like to revive the discussion that arose during the last CommitFest over
the proper design for identifying no-op length coercions like varchar(4) -
varchar(8). Here is the root of the original debate:
Robert Haas robertmh...@gmail.com writes:
On Mon, May 23, 2011 at 12:42 PM, Noah Misch n...@leadboat.com wrote:
There were two proposals on the table:
1. Attach a f(from_typmod, to_typmod, is_explicit) RETURNS boolean function
to the pg_cast; call it in find_coercion_pathway()
2. Attach a
On Mon, May 23, 2011 at 1:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, May 23, 2011 at 12:42 PM, Noah Misch n...@leadboat.com wrote:
There were two proposals on the table:
1. Attach a f(from_typmod, to_typmod, is_explicit) RETURNS boolean
Robert Haas robertmh...@gmail.com writes:
On Mon, May 23, 2011 at 1:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
... But I remain of the opinion that that's the wrong place
to put it.
So you said here:
http://archives.postgresql.org/pgsql-hackers/2011-01/msg02575.php
On Mon, May 23, 2011 at 1:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Maybe. But casts would be the least of our concerns if we were trying
to change the column type. Changing typmod doesn't affect the set of
operations that could be applied to a column, whereas changing type
surely does.
OK,
On Mon, May 23, 2011 at 02:11:39PM -0400, Robert Haas wrote:
On Mon, May 23, 2011 at 1:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Maybe. ?But casts would be the least of our concerns if we were trying
to change the column type. ?Changing typmod doesn't affect the set of
operations that could
On Mon, May 23, 2011 at 2:46 PM, Noah Misch n...@leadboat.com wrote:
On Mon, May 23, 2011 at 02:11:39PM -0400, Robert Haas wrote:
On Mon, May 23, 2011 at 1:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Maybe. ?But casts would be the least of our concerns if we were trying
to change the column
Noah Misch n...@leadboat.com writes:
Good deal. Given that conclusion, the other policy decision I anticipate
affecting this particular patch is the choice of syntax. Presumably, it will
be
a new common_func_opt_item. When I last looked at the keywords list and tried
to come up with
On Mon, May 23, 2011 at 12:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Given that the helper function is going to have a
signature along the lines of (internal, internal) - internal, it's
going to be difficult for anyone to use it for non-builtin functions
anyhow.
I hate to go around in
Greg Stark gsst...@mit.edu writes:
This was the thing that concerned me. If anyone wants to add this
feature for a new data type they're going to have to understand and
tie their code to all this internal parser node stuff. That means
their code will be much more closely tied to a specific
On Mon, May 23, 2011 at 02:53:01PM -0400, Robert Haas wrote:
On Mon, May 23, 2011 at 2:46 PM, Noah Misch n...@leadboat.com wrote:
On Mon, May 23, 2011 at 02:11:39PM -0400, Robert Haas wrote:
On Mon, May 23, 2011 at 1:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Maybe. ?But casts would be the
On Mon, May 23, 2011 at 03:01:40PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
Good deal. Given that conclusion, the other policy decision I anticipate
affecting this particular patch is the choice of syntax. Presumably, it
will be
a new common_func_opt_item. When I
32 matches
Mail list logo
