Re: Declaring a field that is also an out parameter in a function

[Pavel Stehule]

ne 7. 7. 2024 v 0:14 odesílatel Tom Lane  napsal:

> Michael Nolan  writes:
> > Shouldn't declaring a field that is also an OUT parameter throw an error?
>
> No.  The DECLARE is a block nested within the function,
> and the parameter is declared at function scope.
> So this is a standard case of an inner declaration masking
> an outer one.
>
> Possibly plpgsql_check can be set to complain about such cases,
> but they're legal according to the language specification.
>

yes, it does

(2024-07-07 09:27:14) postgres=# select * from
plpgsql_check_function('test_function');
┌───┐
│plpgsql_check_function │
╞═══╡
│ warning:0:10:statement block:parameter "d3" is overlapped │
│ Detail: Local variable overlap function parameter.│
│ warning extra:0:8:DECLARE:never read variable "d3"│
│ warning extra:0:unused parameter "$1" │
│ warning extra:0:unused parameter "$2" │
│ warning extra:0:unused parameter "$3" │
│ warning extra:0:unmodified OUT variable "d3"  │
└───┘
(7 rows)

but looks so there are false alarms related to using an alias. It is
interesting so I have not any report about this issue, so probably using
aliases is not too common today.

Regards

Pavel


>
> regards, tom lane
>
>
>

Re: Declaring a field that is also an out parameter in a function

[Pavel Stehule]

ne 7. 7. 2024 v 9:31 odesílatel Pavel Stehule 
napsal:

>
>
> ne 7. 7. 2024 v 0:14 odesílatel Tom Lane  napsal:
>
>> Michael Nolan  writes:
>> > Shouldn't declaring a field that is also an OUT parameter throw an
>> error?
>>
>> No.  The DECLARE is a block nested within the function,
>> and the parameter is declared at function scope.
>> So this is a standard case of an inner declaration masking
>> an outer one.
>>
>> Possibly plpgsql_check can be set to complain about such cases,
>> but they're legal according to the language specification.
>>
>
> yes, it does
>
> (2024-07-07 09:27:14) postgres=# select * from
> plpgsql_check_function('test_function');
> ┌───┐
> │plpgsql_check_function │
> ╞═══╡
> │ warning:0:10:statement block:parameter "d3" is overlapped │
> │ Detail: Local variable overlap function parameter.│
> │ warning extra:0:8:DECLARE:never read variable "d3"│
> │ warning extra:0:unused parameter "$1" │
> │ warning extra:0:unused parameter "$2" │
> │ warning extra:0:unused parameter "$3" │
> │ warning extra:0:unmodified OUT variable "d3"  │
> └───┘
> (7 rows)
>
> but looks so there are false alarms related to using an alias. It is
> interesting so I have not any report about this issue, so probably using
> aliases is not too common today.
>

I was blind, plpgsql_check is correct

Regards

Pavel


>
> Regards
>
> Pavel
>
>
>>
>> regards, tom lane
>>
>>
>>

Re: Declaring a field that is also an out parameter in a function

[Michael Nolan]

On Sun, Jul 7, 2024 at 4:13 AM Pavel Stehule  wrote:
>
> but looks so there are false alarms related to using an alias. It is 
> interesting so I have not any report about this issue, so probably using 
> aliases is not too common today.

I'm not sure why there's a warning about using an alias. 43.3.1 says
to use them for improved readability.

Mike Nolan

Re: Declaring a field that is also an out parameter in a function

[Tom Lane]

Pavel Stehule  writes:
> (2024-07-07 09:27:14) postgres=# select * from
> plpgsql_check_function('test_function');
> ┌───┐
> │plpgsql_check_function │
> ╞═══╡
> │ warning:0:10:statement block:parameter "d3" is overlapped │
> │ Detail: Local variable overlap function parameter.│

Nice!  FWIW, I think the standard terminology is "local variable
shadows function parameter".

regards, tom lane

Re: Declaring a field that is also an out parameter in a function

[Pavel Stehule]

ne 7. 7. 2024 v 15:01 odesílatel Michael Nolan  napsal:

> On Sun, Jul 7, 2024 at 4:13 AM Pavel Stehule 
> wrote:
> >
> > but looks so there are false alarms related to using an alias. It is
> interesting so I have not any report about this issue, so probably using
> aliases is not too common today.
>
> I'm not sure why there's a warning about using an alias. 43.3.1 says
> to use them for improved readability.
>

it is obsolete - aliases were used when Postgres doesn't support named
arguments.

I  don't know any good reason why one variable can use more than one name.

There can be an exception when argument names are very long, but generally
they are not used.



>
> Mike Nolan
>

Re: Declaring a field that is also an out parameter in a function

[David G. Johnston]

On Sunday, July 7, 2024, Michael Nolan  wrote:

> On Sun, Jul 7, 2024 at 4:13 AM Pavel Stehule 
> wrote:
> >
> > but looks so there are false alarms related to using an alias. It is
> interesting so I have not any report about this issue, so probably using
> aliases is not too common today.
>
> I'm not sure why there's a warning about using an alias. 43.3.1 says
> to use them for improved readability.
>
>
Mostly because you should just name variables correctly the first time.  It
improves readability if you use $n parameter names, which you should not.
As noted in 43.3.2, sometimes you don’t have a choice, though new and old
aren’t usually problematic enough to warrant aliasing.

David J.

Re: Declaring a field that is also an out parameter in a function

[Adrian Klaver]

On 7/7/24 07:42, Pavel Stehule wrote:

I'm not sure why there's a warning about using an alias. 43.3.1 says
to use them for improved readability.


it is obsolete - aliases were used when Postgres doesn't support named 
arguments.


Is that was what it was complaining about or the fact they where 
declared and never used?




I  don't know any good reason why one variable can use more than one name.


Section 43.3.2. ALIAS provides the pros/cons.



There can be an exception when argument names are very long, but 
generally they are not used.




Mike Nolan



--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Declaring a field that is also an out parameter in a function

[Pavel Stehule]

ne 7. 7. 2024 v 16:48 odesílatel Adrian Klaver 
napsal:

> On 7/7/24 07:42, Pavel Stehule wrote:
> > I'm not sure why there's a warning about using an alias. 43.3.1 says
> > to use them for improved readability.
> >
> >
> > it is obsolete - aliases were used when Postgres doesn't support named
> > arguments.
>
> Is that was what it was complaining about or the fact they where
> declared and never used?
>

I am not sure if I understand the question. My  reply was related to
generic usage of aliases.

Report from plpgsql_check was correct - and related variables were not
used.


> >
> > I  don't know any good reason why one variable can use more than one
> name.
>
> Section 43.3.2. ALIAS provides the pros/cons.
>
> >
> > There can be an exception when argument names are very long, but
> > generally they are not used.
> >
> >
> >
> > Mike Nolan
> >
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
>

Re: Declaring a field that is also an out parameter in a function

[Pavel Stehule]

ne 7. 7. 2024 v 16:37 odesílatel Tom Lane  napsal:

> Pavel Stehule  writes:
> > (2024-07-07 09:27:14) postgres=# select * from
> > plpgsql_check_function('test_function');
> > ┌───┐
> > │plpgsql_check_function │
> > ╞═══╡
> > │ warning:0:10:statement block:parameter "d3" is overlapped │
> > │ Detail: Local variable overlap function parameter.│
>
> Nice!  FWIW, I think the standard terminology is "local variable
> shadows function parameter".
>

fixed


>
> regards, tom lane
>

Re: Declaring a field that is also an out parameter in a function

[Adrian Klaver]

On 7/7/24 07:53, Pavel Stehule wrote:



ne 7. 7. 2024 v 16:48 odesílatel Adrian Klaver 
mailto:adrian.kla...@aklaver.com>> napsal:


On 7/7/24 07:42, Pavel Stehule wrote:
 >     I'm not sure why there's a warning about using an alias.
43.3.1 says
 >     to use them for improved readability.
 >
 >
 > it is obsolete - aliases were used when Postgres doesn't support
named
 > arguments.

Is that was what it was complaining about or the fact they where
declared and never used?


I am not sure if I understand the question. My  reply was related to 
generic usage of aliases.


The conversation was:

Mike Nolan

"I'm not sure why there's a warning about using an alias. 43.3.1 says
to use them for improved readability."

Pavel Stehule

"it is obsolete - aliases were used when Postgres doesn't support named 
arguments."


I was just trying to confirm that the warning was not for ALIAS being 
declared. That it was for what you state below.





Report from plpgsql_check was correct - and related variables were not 
used.



 >
 > I  don't know any good reason why one variable can use more than
one name.

Section 43.3.2. ALIAS provides the pros/cons.

 >
 > There can be an exception when argument names are very long, but
 > generally they are not used.
 >
 >
 >
 >     Mike Nolan
 >

-- 
Adrian Klaver

adrian.kla...@aklaver.com 



--
Adrian Klaver
adrian.kla...@aklaver.com

Re: Declaring a field that is also an out parameter in a function

[Pavel Stehule]

ne 7. 7. 2024 v 17:00 odesílatel Adrian Klaver 
napsal:

> On 7/7/24 07:53, Pavel Stehule wrote:
> >
> >
> > ne 7. 7. 2024 v 16:48 odesílatel Adrian Klaver
> > mailto:adrian.kla...@aklaver.com>> napsal:
> >
> > On 7/7/24 07:42, Pavel Stehule wrote:
> >  > I'm not sure why there's a warning about using an alias.
> > 43.3.1 says
> >  > to use them for improved readability.
> >  >
> >  >
> >  > it is obsolete - aliases were used when Postgres doesn't support
> > named
> >  > arguments.
> >
> > Is that was what it was complaining about or the fact they where
> > declared and never used?
> >
> >
> > I am not sure if I understand the question. My  reply was related to
> > generic usage of aliases.
>
> The conversation was:
>
> Mike Nolan
>
> "I'm not sure why there's a warning about using an alias. 43.3.1 says
> to use them for improved readability."
>
> Pavel Stehule
>
> "it is obsolete - aliases were used when Postgres doesn't support named
> arguments."
>
> I was just trying to confirm that the warning was not for ALIAS being
> declared. That it was for what you state below.
>
>
ok



>
> >
> > Report from plpgsql_check was correct - and related variables were not
> > used.
> >
> >
> >  >
> >  > I  don't know any good reason why one variable can use more than
> > one name.
> >
> > Section 43.3.2. ALIAS provides the pros/cons.
> >
> >  >
> >  > There can be an exception when argument names are very long, but
> >  > generally they are not used.
> >  >
> >  >
> >  >
> >  > Mike Nolan
> >  >
> >
> > --
> > Adrian Klaver
> > adrian.kla...@aklaver.com 
> >
>
> --
> Adrian Klaver
> adrian.kla...@aklaver.com
>
>

Re: Load a csv or a avro?

[Adrian Klaver]

On 7/6/24 13:09, sud wrote:
On Fri, Jul 5, 2024 at 8:24 PM Adrian Klaver > wrote:


On 7/5/24 02:08, sud wrote:
 > Hello all,
 >
 > Its postgres database. We have option of getting files in csv
and/or in
 > avro format messages from another system to load it into our
postgres
 > database. The volume will be 300million messages per day across many
 > files in batches.

Are dumping the entire contents of each file or are you pulling a
portion of the data out?



Yes, all the fields in the file have to be loaded to the columns in the 
tables in postgres. But how will that matter here for deciding if we 
should ask the data in .csv or .avro format from the outside system to 
load into the postgres database in row and column format? Again my 
understanding was that irrespective of anything , the .csv file load 
will always faster as because the data is already stored in row and 
column format as compared to the .avro file in which the parser has to 
perform additional job to make it row and column format or map it to the 
columns of the database table. Is my understanding correct here?


If you are going to use complete rows and all rows then COPY of CSV in 
Postgres would be your best choice.


--
Adrian Klaver
adrian.kla...@aklaver.com