Mark Dilger wrote:
> >>
relpartbound |
relpartbound
| ?column? | ?column?
> >>
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+----------
> >> {PARTITIONBOUNDSPEC :strategy l :listdatums ({CONST :consttype 23000 :consttypmod -1 :constcollid 0 :constlen 2
:constbyvaltrue :constisnull false :location -1 :constvalue 2 [ 0 0 0 0 0 0 0 0 ]}) :lowerdatums <> :upperdatums <>
:location82} | {PARTITIONBOUNDSPEC :strategy l :listdatums ({CONST :consttype 23000 :consttypmod -1 :constcollid 0
:constlen2 :constbyval true :constisnull false :location -1 :constvalue 2 [ 0 0 0 0 0 0 0 0 ]}) :lowerdatums <>
:upperdatums<> :location 73} | f | f
> >> (1 row)
> I concede that mitigates the problem somewhat, though I still think a user may look
> at pg_class, see there is a column that appears to show the partition boundaries,
> and then decide to check whether two tables have the same partition boundaries
> by comparing those fields, without passing them first through pg_get_expr(), a
> function they may never have heard of.
How do you expect that the used would actually interpret the above
weird-looking value? There's no way to figure out what operations are
being done in that ugly blob of text.
I suspect it would be better to reduce the location field to -1 as
proposed, though, since the location has no actual meaning once the node
is stored standalone rather than as part of a larger command. However
it's clear that we're not consistent about doing this elsewhere.
> To me, it seems odd to immortalize a SQL parsing field in the catalog definition of
> the relation, but perhaps that's just my peculiar sensibilities. If the community is more
> on your side, I'm not going to argue it.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
