Well, I noticed that, too, but I didn't think it was my job to tell
the patch author what functions he should have wanted. A follow-on
patch to add to_regprocedure and to_regoperator wouldn't be much work,
if you want that.
And here is a patch for that.
Looks good to me except duplicate
On Wed, Apr 16, 2014 at 3:27 AM, Tatsuo Ishii is...@postgresql.org wrote:
Well, I noticed that, too, but I didn't think it was my job to tell
the patch author what functions he should have wanted. A follow-on
patch to add to_regprocedure and to_regoperator wouldn't be much work,
if you want
On Mon, 7 Apr 2014 12:00:49 -0400
Robert Haas robertmh...@gmail.com wrote:
In other words, let's revert the whole refactoring of this file to
create reg*_guts functions, and instead just copy the relevant logic
for the name lookups into the new functions. For to_regproc(), for
example, it
On Tue, Apr 8, 2014 at 3:01 AM, Yugo Nagata nag...@sraoss.co.jp wrote:
On Mon, 7 Apr 2014 12:00:49 -0400
Robert Haas robertmh...@gmail.com wrote:
In other words, let's revert the whole refactoring of this file to
create reg*_guts functions, and instead just copy the relevant logic
for the
Robert Haas robertmh...@gmail.com writes:
Looks good, committed with a bit of further cleanup.
I had not actually paid attention to the non-regclass parts of this, and
now that I look, I've got to say that it seems borderline insane to have
chosen to implement regproc/regoper rather than
On Tue, Apr 8, 2014 at 10:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Looks good, committed with a bit of further cleanup.
I had not actually paid attention to the non-regclass parts of this, and
now that I look, I've got to say that it seems borderline
On Tue, Apr 8, 2014 at 11:01 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Apr 8, 2014 at 10:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Looks good, committed with a bit of further cleanup.
I had not actually paid attention to the non-regclass
On Sat, Apr 5, 2014 at 1:10 AM, Amit Kapila amit.kapil...@gmail.com wrote:
The reason of this behavior is that in out functions (regclassout), we return
the OID as it is incase it doesn't exist. One way to fix this is incase of
OID input parameters, we check if the passed OID exists in to_*
Robert Haas robertmh...@gmail.com writes:
In other words, let's revert the whole refactoring of this file to
create reg*_guts functions, and instead just copy the relevant logic
for the name lookups into the new functions.
The main discomfort I'd had with this patch was the amount of
On 2014-04-04 11:18:10 -0400, Robert Haas wrote:
On Wed, Apr 2, 2014 at 11:27 PM, Amit Kapila amit.kapil...@gmail.com wrote:
Right, it will get reset in error. However still we need to free for
missing_ok
case and when it is successful in getting typeid. So don't you think it is
better
Andres Freund and...@2ndquadrant.com writes:
There's actually another good reason to not copy regclass's behaviour:
postgres=# CREATE TABLE 123();
CREATE TABLE
postgres=# SELECT '123'::regclass;
regclass
--
123
(1 row)
I don't think that's fixable for ::regclass, but we
On 2014-04-07 12:59:36 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
There's actually another good reason to not copy regclass's behaviour:
postgres=# CREATE TABLE 123();
CREATE TABLE
postgres=# SELECT '123'::regclass;
regclass
--
123
(1 row)
On Fri, Apr 4, 2014 at 8:48 PM, Robert Haas robertmh...@gmail.com wrote:
I see. Here's an updated patch with a bit of minor refactoring to
clean that up, and some improvements to the documentation.
I was all ready to commit this when I got cold feet. What's bothering
me is that the patch,
On Wed, Apr 2, 2014 at 1:41 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Mon, Mar 31, 2014 at 7:08 PM, Yugo Nagata nag...@sraoss.co.jp wrote:
Hi Amit Kapila,
Thank you for your reviewing. I updated the patch to v5.
I have checked the latest version and found few minor improvements that
On Thu, Apr 3, 2014 at 5:43 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Apr 2, 2014 at 1:41 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Mon, Mar 31, 2014 at 7:08 PM, Yugo Nagata nag...@sraoss.co.jp wrote:
Hi Amit Kapila,
Thank you for your reviewing. I updated the patch to v5.
On Mon, Mar 31, 2014 at 7:08 PM, Yugo Nagata nag...@sraoss.co.jp wrote:
Hi Amit Kapila,
Thank you for your reviewing. I updated the patch to v5.
I have checked the latest version and found few minor improvements that
are required:
1.
! if (!missing_ok)
! ereport(ERROR,
!
On Sat, Mar 22, 2014 at 1:17 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Wed, Feb 26, 2014 at 11:56 AM, Yugo Nagata nag...@sraoss.co.jp wrote:
Thanks for your a lot of comments. I revised the patch according to
comments from Robert Haas and Marti Raudsepp.
I have started looking into
On Sun, Mar 23, 2014 at 7:57 AM, Amit Kapila amit.kapil...@gmail.com wrote:
Anyone has any objection for this behaviour difference between
usage of ::regclass and to_regclass()?
No, I think that makes a lot of sense given the behavior -- if the
object is not there, to_regclass() just returns
On Wed, Feb 26, 2014 at 11:56 AM, Yugo Nagata nag...@sraoss.co.jp wrote:
Thanks for your a lot of comments. I revised the patch according to
comments from Robert Haas and Marti Raudsepp.
I have started looking into this patch and below are my
initial findings:
1. Dependency is not recorded
On Sat, Mar 22, 2014 at 1:17 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Wed, Feb 26, 2014 at 11:56 AM, Yugo Nagata nag...@sraoss.co.jp wrote:
Thanks for your a lot of comments. I revised the patch according to
comments from Robert Haas and Marti Raudsepp.
I have started looking into
On Tue, Jan 28, 2014 at 10:38 AM, Yugo Nagata nag...@sraoss.co.jp wrote:
I revised the patch. Could you please review this?
I didn't test the patch due to the duplicate OID compilation error.
But a few things stuck out from the diffs:
* You added some unnecessary spaces at the beginning of the
message --
From: Marti Raudsepp ma...@juffo.org
Date: Thu, Jan 23, 2014 at 3:39 AM
Subject: Re: [HACKERS] Proposal: variant of regclass
To: Yugo Nagata nag...@sraoss.co.jp
Cc: Tatsuo Ishii is...@postgresql.org, pgsql-hackers
pgsql-hackers@postgresql.org, Vik Fearing vik.fear
On Fri, Jan 31, 2014 at 6:31 AM, Yugo Nagata nag...@sraoss.co.jp wrote:
Hi Amit,
Thanks for your reviewing. I updated the patch.
I fixed the oids and removed the witespace.
This patch contains several whitespace-only hunks. Please revert them.
I don't like the changes to
On 22 January 2014 13:09, Tatsuo Ishii is...@postgresql.org wrote:
I, as a user would be happier if we also have to_regprocedure() and
to_regoperator(). The following query looks a valid use-case where one
needs to find if a particular function exists. Using to_regproc('sum')
does
not
for srasce.sra.co.jp loops back to myself
t-is...@sra.co.jp: mail for srasce.sra.co.jp loops back to myself
-- Forwarded message --
From: Marti Raudsepp ma...@juffo.org
Date: Thu, Jan 23, 2014 at 3:39 AM
Subject: Re: [HACKERS] Proposal: variant of regclass
To: Yugo Nagata nag...@sraoss.co.jp
On Tue, Jan 14, 2014 at 9:28 AM, Yugo Nagata nag...@sraoss.co.jp wrote:
Here is the patch to implement to_regclass, to_regproc, to_regoper,
and to_regtype.
+ static Datum regclass_guts(char *class_name_or_oid, bool raiseError);
Minor bikeshedding, a lot of code currently uses an argument named
On Tue, Jan 14, 2014 at 9:28 AM, Yugo Nagata nag...@sraoss.co.jp wrote:
Here is the patch to implement to_regclass, to_regproc, to_regoper,
and to_regtype.
+ static Datum regclass_guts(char *class_name_or_oid, bool raiseError);
Minor bikeshedding, a lot of code currently uses an argument
On Wed, 22 Jan 2014 20:04:12 +0900 (JST)
Tatsuo Ishii is...@postgresql.org wrote:
On Tue, Jan 14, 2014 at 9:28 AM, Yugo Nagata nag...@sraoss.co.jp wrote:
Here is the patch to implement to_regclass, to_regproc, to_regoper,
and to_regtype.
+ static Datum regclass_guts(char
On Wed, Jan 22, 2014 at 1:44 PM, Yugo Nagata nag...@sraoss.co.jp wrote:
On Wed, 22 Jan 2014 20:04:12 +0900 (JST)
Tatsuo Ishii is...@postgresql.org wrote:
parseTypeString() is called by some other functions and I avoided
influences of modifying the definition on them, since this should
raise
I, as a user would be happier if we also have to_regprocedure() and
to_regoperator(). The following query looks a valid use-case where one
needs to find if a particular function exists. Using to_regproc('sum') does
not make sense here because it will return InvalidOid, which will not tell
us
Hi,
I have begun the review as part of the commitfest. Below are my comments
*_guts() functions are defined as returning Datum, while they are actually
returning Oid. They should be defined as returning Oid.
Also the PG_RETURN_OID() has been still used in some of the *_guts()
On Tue, Jan 14, 2014 at 4:28 PM, Yugo Nagata nag...@sraoss.co.jp wrote:
Here is the patch to implement to_regclass, to_regproc, to_regoper,
and to_regtype. They are new functions similar to regclass, regproc,
regoper, and regtype except that if requested object is not found,
returns
Hi,
On Tue, Jan 14, 2014 at 4:28 PM, Yugo Nagata nag...@sraoss.co.jp wrote:
Here is the patch to implement to_regclass, to_regproc, to_regoper,
and to_regtype. They are new functions similar to regclass, regproc,
regoper, and regtype except that if requested object is not found,
returns
2013/12/31 Tatsuo Ishii is...@postgresql.org
On 12/31/2013 02:38 AM, Tatsuo Ishii wrote:
Before proceeding the work, I would like to make sure that followings
are complete list of new functions. Inside parentheses are
corresponding original functions.
toregproc (regproc)
toregoper
It seems fine to me if the new function ignores the specific error of
relation does not exist while continuing to throw other errors.
Thanks. Here is the revised conceptual patch. I'm going to post a
concrete patch and register it to 2014-01 Commit Fest.
Before proceeding the work, I would
On 12/31/2013 02:38 AM, Tatsuo Ishii wrote:
Before proceeding the work, I would like to make sure that followings
are complete list of new functions. Inside parentheses are
corresponding original functions.
toregproc (regproc)
toregoper (regoper)
toregclass (regclass)
toregtype (regtype)
On 12/31/2013 02:38 AM, Tatsuo Ishii wrote:
Before proceeding the work, I would like to make sure that followings
are complete list of new functions. Inside parentheses are
corresponding original functions.
toregproc (regproc)
toregoper (regoper)
toregclass (regclass)
toregtype (regtype)
For the pgpool-II use case, I'm happy to follow you because pgpool-II
always does a grammatical check (using raw parser) on a query first
and such syntax problem will be pointed out, thus never reaches to
the state where calling toregclass.
One concern is, other users expect toregclass to
On Mon, Dec 16, 2013 at 8:22 PM, Tatsuo Ishii is...@postgresql.org wrote:
static Datum regclass_gut(char *class_name_or_oid, bool raiseError);
static List *stringToQualifiedNameList_gut(const char *string, bool
raiseError);
Please spell that as guts not gut.
Thanks. I see.
regclass_gut
Tatsuo Ishii is...@postgresql.org writes:
Can I make sure that we want to keep the current behavior:
test=# SELECT 'pg_klass'::regclass;
ERROR: relation pg_klass does not exist
Yeah, I think the consensus is to not change the behavior of the input
functions, just add some new ones.
Ok,
Tatsuo Ishii is...@postgresql.org writes:
To implement toregclass, which does not throw errors when invalid
argument is given, src/backend/utils/adt/regproc.c is modified. I
added two static functions:
static Datum regclass_gut(char *class_name_or_oid, bool raiseError);
static List
static Datum regclass_gut(char *class_name_or_oid, bool raiseError);
static List *stringToQualifiedNameList_gut(const char *string, bool
raiseError);
Please spell that as guts not gut.
Thanks. I see.
regclass_gut is called from regclassin and toregclass and do the most
job before
On 2013-12-04 20:25:53 -0500, Tom Lane wrote:
Tatsuo Ishii is...@sraoss.co.jp writes:
I would like to add a variant of regclass, which is exactly same as
current regclass except it does not raise an error when the target
table is not found. Instead it returns InvalidOid (0).
I've
2013/12/5 Andres Freund and...@2ndquadrant.com
On 2013-12-04 20:25:53 -0500, Tom Lane wrote:
Tatsuo Ishii is...@sraoss.co.jp writes:
I would like to add a variant of regclass, which is exactly same as
current regclass except it does not raise an error when the target
table is not
On 2013-12-05 11:54:20 +0100, Pavel Stehule wrote:
2013/12/5 Andres Freund and...@2ndquadrant.com
We can introduce some assert polymorphic function
CREATE OR REPLACE FUNCTION notnull(any, message text) RETURNS any, that can
be used for check inside SQL
Uh. How is that going to help
2013/12/5 Andres Freund and...@2ndquadrant.com
On 2013-12-05 11:54:20 +0100, Pavel Stehule wrote:
2013/12/5 Andres Freund and...@2ndquadrant.com
We can introduce some assert polymorphic function
CREATE OR REPLACE FUNCTION notnull(any, message text) RETURNS any, that
can
be used for
Hello, Andres.
You wrote:
AF On 2013-12-04 20:25:53 -0500, Tom Lane wrote:
Tatsuo Ishii is...@sraoss.co.jp writes:
I would like to add a variant of regclass, which is exactly same as
current regclass except it does not raise an error when the target
table is not found. Instead it returns
Pavel Golub pa...@microolap.com writes:
I personally see two approaches:
1. Implement GUC variable controling this behaviour per session
2. Introduce new safe reg* variables, e.g. sregclass, sregtype etc.
I don't think new types are a good idea. If we are afraid to change
the behavior of the
On 12/5/13, 9:41 AM, Tom Lane wrote:
Pavel Golub pa...@microolap.com writes:
I personally see two approaches:
1. Implement GUC variable controling this behaviour per session
2. Introduce new safe reg* variables, e.g. sregclass, sregtype etc.
I don't think new types are a good idea. If we
Peter Eisentraut pete...@gmx.net writes:
We could invent some sneaky syntax variants, like 'pg_klass'::regclass
errors, but '?pg_klass'::regclass does not.
Hmm ... cute idea, but shoehorning it into regoperator might be
problematic. You'd have to pick a flag character that wasn't a
valid
On Thu, Dec 5, 2013 at 9:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Golub pa...@microolap.com writes:
I personally see two approaches:
1. Implement GUC variable controling this behaviour per session
2. Introduce new safe reg* variables, e.g. sregclass, sregtype etc.
I don't think new
Robert Haas robertmh...@gmail.com writes:
On Thu, Dec 5, 2013 at 9:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I don't think new types are a good idea. If we are afraid to change
the behavior of the input converters, what we should do is introduce
new functions, eg toregclass(text) returns
Robert Haas robertmh...@gmail.com writes:
Another advantage of this approach is that, IIUC, type input functions
can't return a NULL value. So 'pg_klass'::regclass could return 0,
but not NULL. On the other hand, toregclass('pg_klass') *could*
return NULL, which seems conceptually cleaner.
On 12/5/13, 10:08 AM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
We could invent some sneaky syntax variants, like 'pg_klass'::regclass
errors, but '?pg_klass'::regclass does not.
Hmm ... cute idea, but shoehorning it into regoperator might be
problematic. You'd have to pick
On Dec 5, 2013, at 7:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, another arguable advantage of fixing this via new functions is
that users could write equivalent (though no doubt slower) functions
for use in pre-9.4 releases, and thus not need to maintain multiple
versions of app code that
I'm getting less enamored of just-change-the-input-behavior myself.
The case that occurred to me is, suppose somebody's got a table containing
a regclass or regproc column, and he dumps and reloads it. If the input
converter silently replaces unknown names by 0, he's at risk of unexpected
Tatsuo Ishii is...@postgresql.org writes:
Can I make sure that we want to keep the current behavior:
test=# SELECT 'pg_klass'::regclass;
ERROR: relation pg_klass does not exist
Yeah, I think the consensus is to not change the behavior of the input
functions, just add some new ones.
I would like to propose to add a variant of regclass.
Background:
Pgpool-II (http://www.pgpool.net) needs to get information of tables
by querying PostgreSQL's system catalog. For efficiency and
correctness of the info (search path consideration), pgpool-II issues
such queries piggy packing the
Tatsuo Ishii is...@sraoss.co.jp writes:
I would like to add a variant of regclass, which is exactly same as
current regclass except it does not raise an error when the target
table is not found. Instead it returns InvalidOid (0).
I've sometimes thought we should just make all the reg* input
Tatsuo Ishii is...@sraoss.co.jp writes:
I would like to add a variant of regclass, which is exactly same as
current regclass except it does not raise an error when the target
table is not found. Instead it returns InvalidOid (0).
I've sometimes thought we should just make all the reg* input
Hello, Tom.
You wrote:
TL Tatsuo Ishii is...@sraoss.co.jp writes:
I would like to add a variant of regclass, which is exactly same as
current regclass except it does not raise an error when the target
table is not found. Instead it returns InvalidOid (0).
TL I've sometimes thought we should
61 matches
Mail list logo
