Re: The DROP TABLE instruction should have a TEMP option for when a temporary table
Hi Tom,
Thanks a lot, for the response!
Yes, you are right, there is a secure way for drops, prefixing with the
schema name.
But, for this particular case, TEMPORARY tables, as a special way for
CREATE TABLE, It would be good to have also an special way for DROP TABLE.
(It is just an opinion)
Today I realized that,
and I've created my functions:
--/*
;CREATE FUNCTION "dailyDataProcessingEphemerals"."getTemporalSchemaName"()
RETURNS text
AS $$
SELECT quote_ident(nspname) FROM pg_namespace WHERE oid =
pg_my_temp_schema();
$$ LANGUAGE SQL;
-- RUN AS: ;SELECT * FROM
"dailyDataProcessingEphemerals"."getTemporalSchemaName"()
;CREATE FUNCTION
"dailyDataProcessingEphemerals"."dropTemporalTableIfExists"("tableName"
text)
RETURNS void
LANGUAGE "plpgsql"
AS $$
BEGIN
EXECUTE 'DROP TABLE IF EXISTS ' || (SELECT "getTemporalSchemaName" FROM
"dailyDataProcessingEphemerals"."getTemporalSchemaName"()) || '.' ||
quote_ident("tableName");
END $$
--*/
Regards Pablo
El vie., 19 de oct. de 2018 a la(s) 21:33, Tom Lane (t...@sss.pgh.pa.us)
escribió:
> =?utf-8?q?PG_Doc_comments_form?= writes:
> > The issue is related to the intention of drop the temporary table:
> > ;DROP TABLE "myTooImportantTable" -- <--- this drop the
> > "myTooImportantTable"
> > ;DROP TABLE "myTooImportantTable" -- <--- this drop the
> > public."myTooImportantTable"
>
> If you want to be sure you drop a temp table and not a regular one, say
>
> DROP TABLE pg_temp.mytable;
>
> There's no need for new syntax.
>
> regards, tom lane
>
Change pg_attribute textual link to an actual link
In the System catalog/pg_attrdef documentation, there is a reference to pg_attribute with the text “see below”. That makes sense in the PDF version (and similar renderings), but in the web version it seems a bit odd as pg_attribute is on the next page, not below. The attached patch changes it to an actual link instead, but simply removing the “see below” bit is another approach which isn’t out of line with other parts of the documentation (I opted for link since I personally prefer that). cheers ./daniel pg_attrdef_link.patch Description: Binary data
Re: bloom documentation patch
On Wed, Oct 17, 2018 at 11:45 PM Oleg Bartunov wrote: > On Mon, Oct 15, 2018 at 12:48 AM Thomas Munro > wrote: > > > > On Mon, Oct 15, 2018 at 10:15 AM Oleg Bartunov > > wrote: > > > Please, consider attached patch, which improves contrib/bloom > > > documentation. > > > > Hello Oleg, I have no comment on the technical details but here is > > some proof-reading of the English: > > > > + Length of each signature (index entry) in bits, it is rounded > > up to the nearest > > + multiple of 16. The default is 80 bits and > > maximum is > > > > s/, it is/. It is/ > > s/and maximum/and the maximum/ Thank you for these corrections. They are pushed. > > + Bloom AM doesn't supports unique indexes. > > > > s/supports/support/ > > > > + Bloom AM doesn't supports NULL values. > > > > s/supports/support/ These two were already fixed in the version I've pushed before. -- Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Re: Change pg_attribute textual link to an actual link
Daniel Gustafsson writes: > In the System catalog/pg_attrdef documentation, there is a reference to > pg_attribute with the text "see below". That makes sense in the PDF version > (and similar renderings), but in the web version it seems a bit odd as > pg_attribute is on the next page, not below. > The attached patch changes it to an actual link instead, but simply removing > the "see below" bit is another approach which isn't out of line with other > parts of the documentation (I opted for link since I personally prefer that). I agree with your change, but I wonder if the sentence after this one doesn't need some work too. It seems to predate ALTER COLUMN SET DEFAULT. We could add a mention of that, or just stop trying to describe the preconditions, and say something like "only columns for which a default value has been explicitly set will have an entry here". regards, tom lane
Re: remove deprecated @@@ operator ?
On Sun, Oct 21, 2018 at 11:24 PM Tom Lane wrote: > > Oleg Bartunov writes: > > The commit 9b5c8d45f62bd3d243a40cc84deb93893f2f5122 is now 10+ years > > old, may be we could remove deprecated @@@ operator ? > > Is it actually causing any problem? AFAICS it's just a couple extra > pg_operator entries, so why not leave it? > > I'd be +1 for removing it from the docs, though ... attached a tiny patch for docs > > regards, tom lane -- Postgres Professional: http://www.postgrespro.com The Russian Postgres Company func.sgml.patch Description: Binary data
