That having a table and function with similar names causes this problem is
a bug.
Going forward I'll be sure to avoid the problem.
On Wed, Aug 6, 2025 at 5:35 PM David G. Johnston
wrote:
> On Wednesday, August 6, 2025, Rumpi Gravenstein
> wrote:
>
>> Here's a re
db=# select _sa_setup_role('af_repo_app');
>> ERROR: malformed array literal: "af_repo_app"
>> LINE 1: select _sa_setup_role('af_repo_app');
>> ^
>> DETAIL: Array value must start with "{" or dimension information.
>> xxx_pub_dev_2_db=#
>>
>
> Yeah, we’ve already pretty much decided this function has nothing to do
> with it. Go look at pg_type per the last example demonstrating the same
> error without the involvement of any user-defined function.
>
> David J.
>
>
--
Rumpi Gravenstein
; is interpreted as the corresponding array type:
>
> Oh, of course --- that's a good deal more likely than my version.
>
> regards, tom lane
>
--
Rumpi Gravenstein
DBA
to confirm.
This issue only appears in the function I have listed. A similar function,
same contents and parameter but with a different name, works the way I
would expect.
On Fri, Jul 25, 2025 at 1:10 PM Tom Lane wrote:
> Rumpi Gravenstein writes:
> > No ... just one version:
>
le | character varying | p_role_to_be_granted
character varying | func
(1 row)
_pub_dev_2_db=#
_pub_dev_2_db=#
On Fri, Jul 25, 2025 at 1:02 PM Adrian Klaver
wrote:
> On 7/25/25 09:59, Rumpi Gravenstein wrote:
> > No ... just one version:
> >
>
> >
> > _p
ma | Name | Result data type | Argument data types
| Type
++---++--
sqlapp | _sa_setup_role | character varying | p_role_to_be_granted
character varying | func
(1 row)
On Fri, Jul 25, 20
ed::varchar;
return('Done');
end;
$function$;
select _sa_setup_role('af_repo_app');
select _sa_setup_role('af_repo_app'::varchar);
Best Regards
--
Rumpi Gravenstein
Wait...I see my issue. Duh! The where clause is applied after the CTE is
evaluated
On Fri, Aug 30, 2024 at 7:37 AM Rumpi Gravenstein
wrote:
>
> that the lag() functions are seeing some rows that don't show up in
> the final output.
>
>
> I'm under the impression
d?
On Thu, Aug 29, 2024 at 8:07 PM Tom Lane wrote:
> Rumpi Gravenstein writes:
> > Is this a PostgreSQL bug?
>
> Maybe, but you haven't provided enough information to let anyone else
> reproduce the behavior.
>
> Personally I'm suspicious that because yo
token where logical_partition_key='TEST_DATA' and
usage_text='F(T61)(EXPORT)';
Which returns:
logical_partition_keyusage_texttxtrpo_txtindxmx_indxprvnxtnxt2prv2prv3
"TEST_DATA"
"F(T61)(EXPORT)" "F(T61)(EXPORT)" "F" "1" "7" *"F"* "(" "(" "[NULL]"
"[NULL]"
"TEST_DATA"
"F(T61)(EXPORT)" "F(T61)(EXPORT)" "(" "2" "7" "F" "(" "T61" "F" "[NULL]"
"TEST_DATA"
"F(T61)(EXPORT)" "F(T61)(EXPORT)" "T61" "3" "7" *"T61"* ")" ")" "(" "("
"TEST_DATA"
"F(T61)(EXPORT)" "F(T61)(EXPORT)" ")" "4" "7" "T61" ")" "(" "T61" "("
"TEST_DATA"
"F(T61)(EXPORT)" "F(T61)(EXPORT)" "(" "5" "7" "*("* "EXPORT" "EXPORT" ")"
")"
"TEST_DATA"
"F(T61)(EXPORT)" "F(T61)(EXPORT)" "EXPORT" "6" "7" "(" "EXPORT" ")" "(" ")"
"TEST_DATA"
"F(T61)(EXPORT)" "F(T61)(EXPORT)" ")" "7" "7" ")" "[NULL]" "[NULL]" "EXPORT"
"EXPORT"
Notice that the prv column (lag - 1 ) is just wrong. I've highlighted
obvious bad values. Other columns are wrong as well.
Is this a PostgreSQL bug?
--
Rumpi Gravenstein
d would be
willing to come to Cleveland, I'd be interested in discussing this
opportunity with them.
Best Regards,
--
Rumpi Gravenstein
Tom/Christophe I now understand. Thanks for the clear explanation.
On Fri, Jan 27, 2023 at 4:16 PM Tom Lane wrote:
> Rumpi Gravenstein writes:
> > We are using the pg_indexes view (indexdef) to retrieve the index
> > definition.
>
> Ah.
>
> > Are you saying tha
you mean
> is that some tool is presenting the indexes to you that way.
>
> If that tool is pg_dump, this is its normal behavior. There will
> be other commands in its output that build the rest of the
> partitioned index set.
>
> regards, tom lane
>
--
Rumpi Gravenstein
r
wrote:
> On 1/27/23 12:23, Rumpi Gravenstein wrote:
> > We are on PostgreSQL 14.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC)
> > 8.5.0 20210514 (Red Hat 8.5.0-10), 64-bitPostgreSQL 14.5 on
> > x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat
> > 8.5.0-1
Whoops ... fixed the subject line.
On Fri, Jan 27, 2023 at 3:23 PM Rumpi Gravenstein
wrote:
> We are on PostgreSQL 14.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC)
> 8.5.0 20210514 (Red Hat 8.5.0-10), 64-bitPostgreSQL 14.5 on
> x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 2021
ion. I
am wondering if this is a side-effect of some other activity. Googling and
looking through documentation haven't helped.
Does anyone have any thoughts on how this might happen?
--
Rumpi Gravenstein
ughts?
--
Rumpi Gravenstein
uot;, per [1].
>
> As the COPYRIGHT file exists at the top of the repo all source code
> underneath, including the contrib directory, is covered.
>
> [1] https://opensource.org/licenses/postgresql
>
> David J.
>
>
--
Rumpi Gravenstein
, Feb 25, 2021 at 6:26 PM Tom Lane wrote:
> Rumpi Gravenstein writes:
> > I am new to PostgreSQL and am unclear on how licensing works for
> PostgreSQL
> > extensions. Are pg_crypto and tablefunc licensed with the PostgreSQL
> > community edition or do PostgreSQL ext
ven't found anything
on-point. Is there a link that describes how each extension is licensed?
--
Rumpi Gravenstein
My use case involves complicated joins on source tables in one schema
loading a target table in the same or a different schema.
On Thu, Feb 25, 2021 at 11:41 AM Rob Sargent wrote:
> On 2/25/21 9:26 AM, Rumpi Gravenstein wrote:
> > Unfortunately, I am not looking to load from an extern
e from external files you should probably look at the PostgreSQL COPY
> command (https://www.postgresql.org/docs/13/sql-copy.html) and additional
> utilities like pg_bulkload (https://github.com/ossc-db/pg_bulkload) .
>
> On Thu, Feb 25, 2021 at 9:45 AM Rumpi Gravenstein
> wrote:
SQL database.
My questions are:
- Is there something comparable within the PostgreSQL community edition
product?
- Are my only options to un-log the table and tune instance memory
parameters?
I've googled for this and can't find a definitive statement on this point.
--
Rumpi Gravenstein
23 matches
Mail list logo