pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #16991: regclass is not case sensitive causing "relation does not exist" error
10+ messages / 5 participants
[nested] [flat]
Commits from this thread:
2021-05-05 f33a178a34 Doc: improve and centralize the documentation for OID alias types.
* BUG #16991: regclass is not case sensitive causing "relation does not exist" error
@ 2021-05-04 10:53 PG Bug reporting form <noreply@postgresql.org>
2021-05-04 13:59 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 10+ messages in thread
From: PG Bug reporting form @ 2021-05-04 10:53 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: cfederico87@gmail.com
The following bug has been logged on the website:
Bug reference: 16991
Logged by: Federico Caselli
Email address: cfederico87@gmail.com
PostgreSQL version: 13.2
Operating system: any
Description:
Hi,
Casting the name of an object to regclass using `name_col::regclass` is very
useful when querying the pg_catalog view to find the relevant information.
This casting does not work if the name of the object to cast is case
sensitive when it comes from a column.
Example using indexes to illustrate:
```sql
begin;
create table example(id serial, value text);
create index "CaseSensitiveIndex" on example (value, id);
create index not_case_sensitive on example (id, value);
select pg_relation_size(indexrelname::regclass) from pg_stat_all_indexes
where indexrelname = 'not_case_sensitive';
select pg_relation_size(indexrelname::regclass) from pg_stat_all_indexes
where indexrelname = 'CaseSensitiveIndex';
rollback;
```
In this example the case the first select using the insensitive
"not_case_sensitive" is correctly casted to regclass, while the second use
using "CaseSensitiveIndex" fails with the error "SQL Error [42P01]: ERROR:
relation "casesensitiveindex" does not exist" suggesting that the case is
not respected by the regclass casting.
While the example makes little sense, since the column "indexrelid" could be
used directly, in many queries the oid of an object is not immediately
available.
Using the "select oid from pg_class where ..." as suggested in the
documentation here https://www.postgresql.org/docs/current/datatype-oid.html
works, but as mentioned in the documentation is not 100% correct.
It think it would be nice if when casting from a column regclass would use
the case sensitive form, like it's possible when using the literal name
directly, like `select '"CaseSensitiveIndex"'::regclass`
Best,
Federico
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error
2021-05-04 10:53 BUG #16991: regclass is not case sensitive causing "relation does not exist" error PG Bug reporting form <noreply@postgresql.org>
@ 2021-05-04 13:59 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-05-04 14:29 ` RE: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Federico <cfederico87@gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Tom Lane @ 2021-05-04 13:59 UTC (permalink / raw)
To: cfederico87@gmail.com; +Cc: pgsql-bugs@lists.postgresql.org
PG Bug reporting form <noreply@postgresql.org> writes:
> Casting the name of an object to regclass using `name_col::regclass` is very
> useful when querying the pg_catalog view to find the relevant information.
> This casting does not work if the name of the object to cast is case
> sensitive when it comes from a column.
This is acting as designed and documented: regclass input conversion acts
the same as the regular SQL parser does, which includes case folding of
unquoted text. If you have input that should be taken literally, you
can apply quote_ident() to it.
Note that your sample query has a second issue: it takes no account of
schemas, so it'll fail if a view row shows a table that is not in your
search_path. Actually-robust solutions to this problem require something
like
(quote_ident(schemaname) || '.' || quote_ident(indexrelname))::regclass
which illustrates why you don't really want regclass to take its input
literally: it needs to be able to interpret schema-qualified names.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* RE: BUG #16991: regclass is not case sensitive causing "relation does not exist" error
2021-05-04 10:53 BUG #16991: regclass is not case sensitive causing "relation does not exist" error PG Bug reporting form <noreply@postgresql.org>
2021-05-04 13:59 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
@ 2021-05-04 14:29 ` Federico <cfederico87@gmail.com>
2021-05-04 14:34 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 10+ messages in thread
From: Federico @ 2021-05-04 14:29 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Thanks for the reply. Taking into consideration the schema as in your
solution does indeed explain the current behavior and it makes sense.
I did not come across that documented behavior while searching for regclass
in the pg docs. The most relevant page I was able to find was the Object
Identifier Types page that does not mention it.
I’ll look into proposing a change in that docs page to mention it, if
that’s the appropriate location for it.
Thanks
Federico Caselli
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error
2021-05-04 10:53 BUG #16991: regclass is not case sensitive causing "relation does not exist" error PG Bug reporting form <noreply@postgresql.org>
2021-05-04 13:59 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
2021-05-04 14:29 ` RE: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Federico <cfederico87@gmail.com>
@ 2021-05-04 14:34 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-05-04 14:43 ` RE: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Federico Caselli <cfederico87@gmail.com>
2021-05-04 23:18 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 10+ messages in thread
From: Tom Lane @ 2021-05-04 14:34 UTC (permalink / raw)
To: Federico <cfederico87@gmail.com>; +Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Federico <cfederico87@gmail.com> writes:
> I did not come across that documented behavior while searching for regclass
> in the pg docs. The most relevant page I was able to find was the Object
> Identifier Types page that does not mention it.
> I’ll look into proposing a change in that docs page to mention it, if
> that’s the appropriate location for it.
Hmm ... I *thought* it was documented, but perhaps not. If not,
it's likely that the other reg* types are likewise underdocumented.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* RE: BUG #16991: regclass is not case sensitive causing "relation does not exist" error
2021-05-04 10:53 BUG #16991: regclass is not case sensitive causing "relation does not exist" error PG Bug reporting form <noreply@postgresql.org>
2021-05-04 13:59 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
2021-05-04 14:29 ` RE: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Federico <cfederico87@gmail.com>
2021-05-04 14:34 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
@ 2021-05-04 14:43 ` Federico Caselli <cfederico87@gmail.com>
1 sibling, 0 replies; 10+ messages in thread
From: Federico Caselli @ 2021-05-04 14:43 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml"; xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=IT link=blue vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span lang=EN-US>It may just be me that did not find it.<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Best,</p><p class=MsoNormal>Federico</p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='border:none;padding:0cm'><b>From: </b><a href="mailto:tgl@sss.pgh.pa.us">Tom Lane</a><br><b>Sent: </b>martedì 4 maggio 2021 16:34<br><b>To: </b><a href="mailto:cfederico87@gmail.com">Federico</a><br><b>Cc: </b><a href="mailto:pgsql-bugs@lists.postgresql.org">pgsql-bugs@lists.postgresql.org</a><br><b>Subject: </b>Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Federico <cfederico87@gmail.com> writes:</p><p class=MsoNormal>> I did not come across that documented behavior while searching for regclass</p><p class=MsoNormal>> in the pg docs. The most relevant page I was able to find was the Object</p><p class=MsoNormal>> Identifier Types page that does not mention it.</p><p class=MsoNormal>> I’ll look into proposing a change in that docs page to mention it, if</p><p class=MsoNormal>> that’s the appropriate location for it.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hmm ... I *thought* it was documented, but perhaps not. If not,</p><p class=MsoNormal>it's likely that the other reg* types are likewise underdocumented.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal> regards, tom lane</p><p class=MsoNormal><o:p> </o:p></p></div></body></html>
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error
2021-05-04 10:53 BUG #16991: regclass is not case sensitive causing "relation does not exist" error PG Bug reporting form <noreply@postgresql.org>
2021-05-04 13:59 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
2021-05-04 14:29 ` RE: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Federico <cfederico87@gmail.com>
2021-05-04 14:34 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
@ 2021-05-04 23:18 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-05-05 07:32 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Laurenz Albe <laurenz.albe@cybertec.at>
1 sibling, 1 reply; 10+ messages in thread
From: Tom Lane @ 2021-05-04 23:18 UTC (permalink / raw)
To: Federico <cfederico87@gmail.com>; +Cc: pgsql-docs@lists.postgresql.org
[ redirecting to pgsql-docs list ]
I wrote:
> Federico <cfederico87@gmail.com> writes:
>> I did not come across that documented behavior while searching for regclass
>> in the pg docs. The most relevant page I was able to find was the Object
>> Identifier Types page that does not mention it.
>> I'll look into proposing a change in that docs page to mention it, if
>> that's the appropriate location for it.
> Hmm ... I *thought* it was documented, but perhaps not. If not,
> it's likely that the other reg* types are likewise underdocumented.
So what I was remembering was some text in the section about sequence
functions. That probably seemed appropriate when they were the only
real use of regclass; but these days we have regclass-accepting functions
all over, not to mention other OID alias types. I propose the attached
patch to move this info into the "Object Identifier Types" section.
regards, tom lane
Attachments:
improve-docs-about-OID-alias-types-1.patch (text/x-diff, 10.8K) download
diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 7c341c8e3f..43f99335dc 100644
--- a/doc/src/sgml/datatype.sgml
+++ b/doc/src/sgml/datatype.sgml
@@ -4780,10 +4780,14 @@ SELECT * FROM pg_attribute
</table>
<para>
- All of the OID alias types for objects grouped by namespace accept
- schema-qualified names, and will
+ All of the OID alias types for objects that are grouped by namespace
+ accept schema-qualified names, and will
display schema-qualified names on output if the object would not
be found in the current search path without being qualified.
+ For example, <literal>myschema.mytable</literal> is acceptable input
+ for <type>regclass</type> (if there is such a table). That value
+ might be output as <literal>myschema.mytable</literal>, or
+ just <literal>mytable</literal>, depending on the current search path.
The <type>regproc</type> and <type>regoper</type> alias types will only
accept input names that are unique (not overloaded), so they are
of limited use; for most uses <type>regprocedure</type> or
@@ -4792,6 +4796,86 @@ SELECT * FROM pg_attribute
operand.
</para>
+ <para>
+ The input functions for these types also ignore whitespace, and will
+ fold upper-case letters to lower case, except within double quotes;
+ this is done to make the syntax rules similar to the way object names
+ are written in SQL. Conversely, the output functions will use double
+ quotes if needed to make the output be a valid SQL identifier. For
+ example, the OID of a function named <literal>Foo</literal> (with
+ upper case <literal>F</literal>) taking two integer arguments could be
+ entered as <literal>' "Foo" ( int, integer ) '::regprocedure</literal>.
+ The output would look like <literal>"Foo"(integer,integer)</literal>.
+ Both the function name and the argument type names could be
+ schema-qualified, too.
+ </para>
+
+ <para>
+ Many built-in <productname>PostgreSQL</productname> functions accept
+ the OID of a table, or another kind of database object, and for
+ convenience are declared as taking <type>regclass</type> (or the
+ appropriate OID alias type). This means you do not have to look up
+ the object's OID by hand, but can just enter its name as a string
+ literal. For example, the <function>nextval()</function> function
+ takes a sequence relation's OID, so you could call it like this:
+<programlisting>
+nextval('foo') <lineannotation>operates on sequence <literal>foo</literal></lineannotation>
+nextval('FOO') <lineannotation>same as above</lineannotation>
+nextval('"Foo"') <lineannotation>operates on sequence <literal>Foo</literal></lineannotation>
+nextval('myschema.foo') <lineannotation>operates on <literal>myschema.foo</literal></lineannotation>
+nextval('"myschema".foo') <lineannotation>same as above</lineannotation>
+nextval('foo') <lineannotation>searches search path for <literal>foo</literal></lineannotation>
+</programlisting>
+ </para>
+
+ <note>
+ <para>
+ When you write the argument of such a function as an unadorned
+ literal string, it becomes a constant of type <type>regclass</type>
+ (or the appropriate type).
+ Since this is really just an OID, it will track the originally
+ identified object despite later renaming, schema reassignment,
+ etc. This <quote>early binding</quote> behavior is usually desirable for
+ object references in column defaults and views. But sometimes you might
+ want <quote>late binding</quote> where the object reference is resolved
+ at run time. To get late-binding behavior, force the constant to be
+ stored as a <type>text</type> constant instead of <type>regclass</type>:
+<programlisting>
+nextval('foo'::text) <lineannotation><literal>foo</literal> is looked up at runtime</lineannotation>
+</programlisting>
+ The <function>to_regclass()</function> function and its siblings
+ can also be used to perform run-time lookups. See
+ <xref linkend="functions-info-catalog-table"/>.
+ </para>
+ </note>
+
+ <para>
+ Another practical example of use of <type>regclass</type>
+ is to look up the OID of a table listed in
+ the <literal>information_schema</literal> views, which don't supply
+ such OIDs directly. One might for example wish to call
+ the <function>pg_relation_size()</function> function, which requires
+ the table OID. Taking the above rules into account, the correct way
+ to do that is
+<programlisting>
+SELECT table_schema, table_name,
+ pg_relation_size((quote_ident(table_schema) || '.' ||
+ quote_ident(table_name))::regclass)
+FROM information_schema.tables
+WHERE ...
+</programlisting>
+ The <function>quote_ident()</function> function will take care of
+ double-quoting the identifiers where needed. The seemingly easier
+<programlisting>
+SELECT pg_relation_size(table_name)
+FROM information_schema.tables
+WHERE ...
+</programlisting>
+ is <emphasis>not recommended</emphasis>, because it will fail for
+ tables that are outside your search path or have names that require
+ quoting.
+ </para>
+
<para>
An additional property of most of the OID alias types is the creation of
dependencies. If a
@@ -4801,19 +4885,13 @@ SELECT * FROM pg_attribute
expression <literal>nextval('my_seq'::regclass)</literal>,
<productname>PostgreSQL</productname>
understands that the default expression depends on the sequence
- <literal>my_seq</literal>; the system will not let the sequence be dropped
- without first removing the default expression.
- <type>regrole</type> is the only exception for the property. Constants of this
- type are not allowed in such expressions.
- </para>
-
- <note>
- <para>
- The OID alias types do not completely follow transaction isolation
- rules. The planner also treats them as simple constants, which may
- result in sub-optimal planning.
+ <literal>my_seq</literal>; then the system will not let the sequence
+ be dropped without first removing the default expression. The
+ alternative of <literal>nextval('my_seq'::text)</literal> does not
+ create a dependency.
+ (<type>regrole</type> is an exception to this property. Constants of this
+ type are not allowed in stored expressions.)
</para>
- </note>
<para>
Another identifier type used by the system is <type>xid</type>, or transaction
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 5ae8abff0c..c60d98360f 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -14429,8 +14429,9 @@ SELECT xmltable.*
<function>table_to_xml</function> maps the content of the named
table, passed as parameter <parameter>table</parameter>. The
<type>regclass</type> type accepts strings identifying tables using the
- usual notation, including optional schema qualifications and
- double quotes. <function>query_to_xml</function> executes the
+ usual notation, including optional schema qualification and
+ double quotes (see <xref linkend="datatype-oid"/> for details).
+ <function>query_to_xml</function> executes the
query whose text is passed as parameter
<parameter>query</parameter> and maps the result set.
<function>cursor_to_xml</function> fetches the indicated number of
@@ -17316,49 +17317,9 @@ SELECT setval('myseq', 42, false); <lineannotation>Next <function>nextval</fu
a <type>regclass</type> argument, which is simply the OID of the sequence in the
<structname>pg_class</structname> system catalog. You do not have to look up the
OID by hand, however, since the <type>regclass</type> data type's input
- converter will do the work for you. Just write the sequence name enclosed
- in single quotes so that it looks like a literal constant. For
- compatibility with the handling of ordinary
- <acronym>SQL</acronym> names, the string will be converted to lower case
- unless it contains double quotes around the sequence name. Thus:
-<programlisting>
-nextval('foo') <lineannotation>operates on sequence <literal>foo</literal></lineannotation>
-nextval('FOO') <lineannotation>operates on sequence <literal>foo</literal></lineannotation>
-nextval('"Foo"') <lineannotation>operates on sequence <literal>Foo</literal></lineannotation>
-</programlisting>
- The sequence name can be schema-qualified if necessary:
-<programlisting>
-nextval('myschema.foo') <lineannotation>operates on <literal>myschema.foo</literal></lineannotation>
-nextval('"myschema".foo') <lineannotation>same as above</lineannotation>
-nextval('foo') <lineannotation>searches search path for <literal>foo</literal></lineannotation>
-</programlisting>
- See <xref linkend="datatype-oid"/> for more information about
- <type>regclass</type>.
+ converter will do the work for you. See <xref linkend="datatype-oid"/>
+ for details.
</para>
-
- <note>
- <para>
- When you write the argument of a sequence function as an unadorned
- literal string, it becomes a constant of type <type>regclass</type>.
- Since this is really just an OID, it will track the originally
- identified sequence despite later renaming, schema reassignment,
- etc. This <quote>early binding</quote> behavior is usually desirable for
- sequence references in column defaults and views. But sometimes you might
- want <quote>late binding</quote> where the sequence reference is resolved
- at run time. To get late-binding behavior, force the constant to be
- stored as a <type>text</type> constant instead of <type>regclass</type>:
-<programlisting>
-nextval('foo'::text) <lineannotation><literal>foo</literal> is looked up at runtime</lineannotation>
-</programlisting>
- </para>
-
- <para>
- Of course, the argument of a sequence function can be an expression
- as well as a constant. If it is a text expression then the implicit
- coercion will result in a run-time lookup.
- </para>
- </note>
-
</sect1>
@@ -26474,11 +26435,8 @@ postgres=# SELECT * FROM pg_walfile_name_offset(pg_stop_backup());
<type>regclass</type> argument, which is simply the OID of the table or index
in the <structname>pg_class</structname> system catalog. You do not have to look up
the OID by hand, however, since the <type>regclass</type> data type's input
- converter will do the work for you. Just write the table name enclosed in
- single quotes so that it looks like a literal constant. For compatibility
- with the handling of ordinary <acronym>SQL</acronym> names, the string
- will be converted to lower case unless it contains double quotes around
- the table name.
+ converter will do the work for you. See <xref linkend="datatype-oid"/>
+ for details.
</para>
<para>
* Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error
2021-05-04 10:53 BUG #16991: regclass is not case sensitive causing "relation does not exist" error PG Bug reporting form <noreply@postgresql.org>
2021-05-04 13:59 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
2021-05-04 14:29 ` RE: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Federico <cfederico87@gmail.com>
2021-05-04 14:34 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
2021-05-04 23:18 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
@ 2021-05-05 07:32 ` Laurenz Albe <laurenz.albe@cybertec.at>
2021-05-05 07:53 ` RE: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Federico Caselli <cfederico87@gmail.com>
2021-05-05 15:28 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 10+ messages in thread
From: Laurenz Albe @ 2021-05-05 07:32 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Federico <cfederico87@gmail.com>; +Cc: pgsql-docs@lists.postgresql.org
On Tue, 2021-05-04 at 19:18 -0400, Tom Lane wrote:
> [ redirecting to pgsql-docs list ]
>
> I wrote:
> > Federico <cfederico87@gmail.com> writes:
> > > I did not come across that documented behavior while searching for regclass
> > > in the pg docs. The most relevant page I was able to find was the Object
> > > Identifier Types page that does not mention it.
> > > I'll look into proposing a change in that docs page to mention it, if
> > > that's the appropriate location for it.
> > Hmm ... I *thought* it was documented, but perhaps not. If not,
> > it's likely that the other reg* types are likewise underdocumented.
>
> So what I was remembering was some text in the section about sequence
> functions. That probably seemed appropriate when they were the only
> real use of regclass; but these days we have regclass-accepting functions
> all over, not to mention other OID alias types. I propose the attached
> patch to move this info into the "Object Identifier Types" section.
That patch looks good to me.
I think it is an improvement to have that discussed under "data types".
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 10+ messages in thread
* RE: BUG #16991: regclass is not case sensitive causing "relation does not exist" error
2021-05-04 10:53 BUG #16991: regclass is not case sensitive causing "relation does not exist" error PG Bug reporting form <noreply@postgresql.org>
2021-05-04 13:59 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
2021-05-04 14:29 ` RE: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Federico <cfederico87@gmail.com>
2021-05-04 14:34 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
2021-05-04 23:18 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
2021-05-05 07:32 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Laurenz Albe <laurenz.albe@cybertec.at>
@ 2021-05-05 07:53 ` Federico Caselli <cfederico87@gmail.com>
1 sibling, 0 replies; 10+ messages in thread
From: Federico Caselli @ 2021-05-05 07:53 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-docs@lists.postgresql.org <pgsql-docs@lists.postgresql.org>
<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml"; xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style></head><body lang=IT link=blue vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span lang=EN-US>The patch is also clear for me, thanks for working on it.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Best,<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>Federico</span></p><p class=MsoNormal><o:p> </o:p></p><div style='mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal style='border:none;padding:0cm'><b>From: </b><a href="mailto:laurenz.albe@cybertec.at">Laurenz Albe</a><br><b>Sent: </b>mercoledì 5 maggio 2021 09:32<br><b>To: </b><a href="mailto:tgl@sss.pgh.pa.us">Tom Lane</a>; <a href="mailto:cfederico87@gmail.com">Federico</a><br><b>Cc: </b><a href="mailto:pgsql-docs@lists.postgresql.org">pgsql-docs@lists.postgresql.org</a><br><b>Subject: </b>Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error</p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>On Tue, 2021-05-04 at 19:18 -0400, Tom Lane wrote:</p><p class=MsoNormal>> [ redirecting to pgsql-docs list ]</p><p class=MsoNormal>> </p><p class=MsoNormal>> I wrote:</p><p class=MsoNormal>> > Federico <cfederico87@gmail.com> writes:</p><p class=MsoNormal>> > > I did not come across that documented behavior while searching for regclass</p><p class=MsoNormal>> > > in the pg docs. The most relevant page I was able to find was the Object</p><p class=MsoNormal>> > > Identifier Types page that does not mention it.</p><p class=MsoNormal>> > > I'll look into proposing a change in that docs page to mention it, if</p><p class=MsoNormal>> > > that's the appropriate location for it.</p><p class=MsoNormal>> > Hmm ... I *thought* it was documented, but perhaps not. If not,</p><p class=MsoNormal>> > it's likely that the other reg* types are likewise underdocumented.</p><p class=MsoNormal>> </p><p class=MsoNormal>> So what I was remembering was some text in the section about sequence</p><p class=MsoNormal>> functions. That probably seemed appropriate when they were the only</p><p class=MsoNormal>> real use of regclass; but these days we have regclass-accepting functions</p><p class=MsoNormal>> all over, not to mention other OID alias types. I propose the attached</p><p class=MsoNormal>> patch to move this info into the "Object Identifier Types" section.</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>That patch looks good to me.</p><p class=MsoNormal>I think it is an improvement to have that discussed under "data types".</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Yours,</p><p class=MsoNormal>Laurenz Albe</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error
2021-05-04 10:53 BUG #16991: regclass is not case sensitive causing "relation does not exist" error PG Bug reporting form <noreply@postgresql.org>
2021-05-04 13:59 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
2021-05-04 14:29 ` RE: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Federico <cfederico87@gmail.com>
2021-05-04 14:34 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
2021-05-04 23:18 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
2021-05-05 07:32 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Laurenz Albe <laurenz.albe@cybertec.at>
@ 2021-05-05 15:28 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-05-05 19:17 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Federico <cfederico87@gmail.com>
1 sibling, 1 reply; 10+ messages in thread
From: Tom Lane @ 2021-05-05 15:28 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; +Cc: Federico <cfederico87@gmail.com>; pgsql-docs@lists.postgresql.org
Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Tue, 2021-05-04 at 19:18 -0400, Tom Lane wrote:
>> So what I was remembering was some text in the section about sequence
>> functions. That probably seemed appropriate when they were the only
>> real use of regclass; but these days we have regclass-accepting functions
>> all over, not to mention other OID alias types. I propose the attached
>> patch to move this info into the "Object Identifier Types" section.
> That patch looks good to me.
> I think it is an improvement to have that discussed under "data types".
Pushed, thanks for reviewing.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error
2021-05-04 10:53 BUG #16991: regclass is not case sensitive causing "relation does not exist" error PG Bug reporting form <noreply@postgresql.org>
2021-05-04 13:59 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
2021-05-04 14:29 ` RE: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Federico <cfederico87@gmail.com>
2021-05-04 14:34 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
2021-05-04 23:18 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
2021-05-05 07:32 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Laurenz Albe <laurenz.albe@cybertec.at>
2021-05-05 15:28 ` Re: BUG #16991: regclass is not case sensitive causing "relation does not exist" error Tom Lane <tgl@sss.pgh.pa.us>
@ 2021-05-05 19:17 ` Federico <cfederico87@gmail.com>
0 siblings, 0 replies; 10+ messages in thread
From: Federico @ 2021-05-05 19:17 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Laurenz Albe <laurenz.albe@cybertec.at>; pgsql-docs@lists.postgresql.org
Thanks for the quick resolution.
Best,
Federico
Ps: sorry for the previous messages in html, I had not realized that the
client I was using were sending the replies like that.
On Wed, 5 May 2021 at 17:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Laurenz Albe <laurenz.albe@cybertec.at> writes:
> > On Tue, 2021-05-04 at 19:18 -0400, Tom Lane wrote:
> >> So what I was remembering was some text in the section about sequence
> >> functions. That probably seemed appropriate when they were the only
> >> real use of regclass; but these days we have regclass-accepting
> functions
> >> all over, not to mention other OID alias types. I propose the attached
> >> patch to move this info into the "Object Identifier Types" section.
>
> > That patch looks good to me.
> > I think it is an improvement to have that discussed under "data types".
>
> Pushed, thanks for reviewing.
>
> regards, tom lane
>
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2021-05-05 19:17 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-05-04 10:53 BUG #16991: regclass is not case sensitive causing "relation does not exist" error PG Bug reporting form <noreply@postgresql.org>
2021-05-04 13:59 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-05-04 14:29 ` Federico <cfederico87@gmail.com>
2021-05-04 14:34 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-05-04 14:43 ` Federico Caselli <cfederico87@gmail.com>
2021-05-04 23:18 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-05-05 07:32 ` Laurenz Albe <laurenz.albe@cybertec.at>
2021-05-05 07:53 ` Federico Caselli <cfederico87@gmail.com>
2021-05-05 15:28 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-05-05 19:17 ` Federico <cfederico87@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox