As I recall, if the listening address is set to '*' but is showing
localhost, then the problem you describe is likely due to missing an IPv6
address in pg_hba.conf. For me, I just added a line to pg_hba.conf like
this:
hostall all ::1/128 md5
So, even t
I think the OP may be referring to Oracle's Temporal Validity feature.
This type of feature has yet to be implemented in PostgreSQL (see
https://www.postgresql.org/docs/13/unsupported-features-sql-standard.html
item T181).
Temporal Validity allows you to add a time dimension to any table, and only
User managed backups in PostgreSQL work very similar to what you know from
Oracle. You first place the cluster in backup mode, then copy the database
files, and lastly take the cluster out of backup mode. The first and last
steps are done using functions pg_start_backup('label',false,false) and
p
On any given server there could be zero, one, or many PGHOME/bin
locations. The OP wants to identify all of them. The default location
used by package-based installers is different from the default location of
software built from source, and when building from source you can specify a
non-default
This all sounds like a previous discussion on pg hackers about a progress
meter for pg_dump. Search the archives for that discussion. Also, search
the web for something like "pg_dump progress meter" and you'll get a few
suggestions like pipe to pv, although that does not appear to work with all
o
Don't you have to select into a variable and then return the variable to
the client per [1]?
Consider the following example from my Oracle system:
beginning code ...
V_SQL := 'SELECT COUNT(*) FROM ' || V_TAB;
EXECUTE IMMEDIATE V_SQL INTO V_CNT;
ending code ...
[1]
https://www.postgresql.org/
Since INSERT /*+APPEND*/ is generally used when bulk loading data into
Oracle 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
I found this error in queries generated from templates query36.tpl,
query70.tpl, and query86.tpl. The problem is, lochierarchy is an alias
defined in the SELECT statement, and the alias isn't being recognized in
the CASE statement. PostgreSQL does not allow a column alias to be
referenced in a CA
The solution depends on how you are creating the tables.
For example: the pg_restore has option —-no-tablespaces. With this option,
all objects will be created in whichever tablespace is the default during
restore. The pg_dump has similar.
If you are running CREATE TABLE statements that have ha
